[APP-421] fix: enforce smallest_time_grain

[briangregoryholmes]

• Prevents queries from being fired with an aggregation granularity that is incompatible with the smallest_time_grain
• Displays error message in aggregation selector
• Adds derivation of grain for additional RillTime subclasses
• Adds getAggregationGrain function
• Fixes an issue where using new Rill Time syntax in YAML defaults would cause the grain to be parsed incorrectly

Checklist:

• Covered by tests
• Ran it and it works as intended
• Reviewed the diff before requesting a review
• Checked for unhandled edge cases
• Linked the issues it closes
• Checked if the docs need to be updated. If so, create a separate Linear DOCS issue
• Intend to cherry-pick into the release branch
• I'm proud of this work!

[AdityaHegde]

This adds a weird state where the data displayed is not for the grain present in the url. Is there a hard requirement to show the warning? If not, would be great if we just correct it in the url as well.

[briangregoryholmes]

This is intentional on my part, but it's not a hard requirement, so I'm happy to consider what others think about it during the applications sync.

The thinking is that I want to avoid ever changing the URL without user input. We are not there yet on Explore, but I think this is a step in the right direction.

I want the URL to be a reliable indicator of what the user has asked for and I think changing it only leads to hiding problems and making things difficult to debug. I want to follow the principle of what you see is what you get it. Sometimes, what you ask for is not what you're allowed to see, but at least we still follow the principle by acknowledging that it's being asked for and displaying a non-blocking error.

You can imagine a situation where a user has manually changed the URL to a grain value that is too small. I think this new UX state is more transparent about what is happening and does a better job of showing that we're guarding against this kind of stuff. Also, if you use a bookmark that has an out of date value, this would make it clear that the bookmark should be updated.

[AdityaHegde]

Looks good from code POV. @ericokuma @nishantmonu51 please approve if we are ok with the UX