Design: Changes to the date selector for queries, for ease of use and physics

[joethreepwood]

Is your feature request related to a problem?

This is a design nit I noticed, so tagging @clarkus

Currently if you select a date range option on a query you're building you see this:

And then you have to select 'Start Date' or 'End date' and then it expands to this:

The problems I see are:

1. This adds an extra click to the flow, because you have to select 'Start date' only to probably then click off of it and choose a date from the calendar view.
2. May hasn't happened yet. It's non-sensical to let me choose a date which hasn't happened yet, either as a start date or an end date. We seem to currently default to showing this month and next month.

Describe the solution you'd like

1. Would seem easier if the calendar view appeared by default and the first click there defaulted to the start date.
2. Don't default to showing dates in future months on the calendar view.

This will mean less clicks and better inputs. Faster, better insights! Woo!

Describe alternatives you've considered

None because my first ideas are always my best ideas.

Additional context

Thank you for your feature request – we love each and every one!

[clarkus]

I think this is mostly an issue of setting reasonable defaults. I agree that we shouldn't allow for future date selection. Secondary to that, we could trigger selection states automatically for some scenarios. It's problematic to click the date control, have to click the start date control, and then actually pick a date. We could just immediately show the date selection prompt here. We could also default the end date to the current date. This would make it so that we're always picking a valid time range and remove the need to select a second date for a common use case.

I recently redesigned the date picker because we were considering absolute date support for cohort creation. It was removed from scope, but the work is still available at https://www.figma.com/file/Y9G24U4r04nEjIDGIEGuKI/PostHog-Design-System-One?node-id=2317%3A2533. I'm mentioning because this iteration overcomes the multi-part range selection by including the range control in the picker itself. Generally a user will just be picking a date or two dates to form a range. If they need to quick edit the values, they can do that via the date controls in the bottom of the component.

[kappa90]

Incorrectly closed after #10462, which is meant to run as an experiment