Monitoring time picker changes should not be implemented in multiple locations

[thomasneirynck]

We have multiple locations where we monitor changes in the time-picker. This should be consolidated in the timepicker itself

From #12811 (comment):

Responding to changes in the time-picker is currently implemented all over the place.

• courier listens on changes to the timepicker, and runs its own loop https://github.com/thomasneirynck/kibana/blob/0d502aec49d8191e49974f215b3c35f9c0207b1b/src/ui/public/courier/courier.js#L130-L130
• Timelion also has its own implementation:
  https://github.com/thomasneirynck/kibana/blob/4c7022a725b9dcd4295c4c980c625a61bad86941/src/core_plugins/timelion/public/app.js#L181-L181
• TSVB also has its own refresher:https://github.com/thomasneirynck/kibana/blob/d8d65526c6afba0e12cbc39fe844ec0a3fb9ba95/src/core_plugins/metrics/public/services/executor_provider.js#L77-L77

The reason Discover works is because it relies on courier.

Visualize - after the refactor - should have its own refresher (triggering a reload event on every tick). This should replace the refresher from TSVB (and perhaps Timelion). Alternatively, we could make this optional, so individual visualizations can opt-in/opt-out of the auto-refreshing functionality.

Also consider that this timing loop should run in the timepicker component itself (https://github.com/thomasneirynck/kibana/blob/5c075f2a3f4eb3bebd2ec7a105b5a03ff8abe292/src/ui/public/timepicker/timepicker.js#L210-L210). That way, all clients of the timepicker can listen to an auto-refresh event. Right now, this logic is flipped.

[epixa]

Sounds like a job for observables. Timepicker exposes an observable to represent the current time range, and then all the various places that need it create a subscription to it.

[timroes]

I think this issue is outdated. Visualizations should be triggered correctly from the outside for refreshing. Apps will still need to manage their time picker correctly, optimizations around that, should be tracked for the new timepicker plugin in #18845.