[Logs UI] [NP followup] Remove legacy_singletons uses

[Kerry350]

legacy_singletons (d805286) have been added to allow certain portions of code to gain access to new platform features (similar to import xyz from 'ui/new_platform) where using the useKibana hook (for proper access to core and plugins) would have been hard / time consuming. These uses are all in logs code (none in metrics) and revolve around the core.http.fetch function. These uses should be refactored away over time. We should not add new uses of this going forward. Below is an example of why this was needed, and why refactoring certain areas would have taken longer:

This example is the log entry rate results hook:

Here's the hook

It uses the useTrackedPromise hook - and if it were the internals of useTrackedPromise itself that managed the creation of the promise and the actual request initiation it would be fine, as we could just use useKibana inside of useTrackedPromise, but it's not.

We could also call useKibana at this useLogEntryRateResults level and pass it as a parameter, but that's not ideal. Instead, we have the createPromise option. In this instance it calls out to callGetLogEntryRateAPI.

This is callGetLogEntryRateAPI.

Just an async function, it's here that http.fetch is imported. We're not in any sort of context we can read from hooks here.

Metrics doesn't have this issue as the useHTTPRequest hook is used, which wraps useTrackedPromise, and thus access to useKibana is simple.

Moving forward logs can either migrate to also using the useHTTPRequest hook, or some other solution.

I do actually like the idea of options for an API call (the path, the body formatting etc) being in separate files. So another idea may be to keep these callGetLogEntryRateAPI style functions, but rather than being responsible for creating a promise and kicking off the request, they could just return an options object, that gets handed off to useHTTPRequest.

[elasticmachine]

Pinging @elastic/logs-metrics-ui (Team:logs-metrics-ui)