Enabling configuration of new relative time range type with range offset in date time picker.

[linuspahl]

Description

With this PR we are enabling the "Until" range select for the relative time range tab which is part of the date time picker.

Because the current relative time range type

{
  type: "relative",
  range: 300,
}

does not support the new property we've implemented another relative time range type with the following structure:

{
  type: "relative",
  from: 300,
  to: 240,
}

To simplify the code we decided to use only use the new relative time range type for the state of the SearchBarForm and TimeRangeDropdown. This means when a user opens a URL like /search?q=&rangetype=relative&relative=300 and executes the search we will change the URL to /search?q=&rangetype=relative&from=300

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Refactoring (non-breaking change)
• Breaking change (fix or feature that would cause existing functionality to change)

[kyleknighted]

Needs validation for the limitDuration of the offset

If a query limit is set, the Range cannot be edited, everything is disabled

[kyleknighted]

I keep clicking submit but the dirty flag never goes away and the URL does not update

[kyleknighted]

left a couple comments

[kyleknighted]

If I set an offset, then submit the form, the URL updates as expected.
But when I open the Date Picker again and change to Absolute tab, the dates are not properly converting so there is an error on the default date.
Then switching back to Relative tab it goes back to the default 5 minutes instead of the date that is currently set with the offset.

Some tab changing logic probably just needs a little care on migrating the date.

[linuspahl]

@kyleknighted I can't reproduce the migration error when changing tabs (relative -> absolute). Can we have a look together?

Regarding "Switching back to Relative tab it goes back to the default 5 minutes instead of the date that is currently set with the offset." As far as I know we never considered the initial time range in the migration strategies in TimeRangeForForm, but I agree that it would be a benefit in most cases. Before we implement this change, let's talk about the different scenarios and how to deal with them.

[kyleknighted]

@linus you're correct, sorry, I was not thinking clearly on what migrateTimeRangeToNewType is doing. Ready to merge once the conflicts are resolved