[NP Migration Phase I]: shim state_management and move to data plugin

[lukeelmers]

Summary

ui/state_management will need to be shimmed into the data plugin as a part of the new platform migration efforts. We need to determine which service is the best "home" for this -- perhaps we will need a new state service.

Checklist for shimming a service into an existing plugin

In most cases, it is recommend to break each of these steps into 3 separate PRs

• 1. Identify all public contracts exposed by the existing service, and update the "destination" plugin to either A) re-export the public contracts; or alternatively b) Move the service to the new plugin and re-export the contracts from the old location, to avoid breaking existing imports.
• 2. Update all downstream modules to import from the new location. This should be done via relative imports: import { setup } from '../../../core_plugins/foo/public/legacy';
• 3. Move the code from its original location to the new location

Background

Phase I ("Move") consists of consolidating (and in some cases separating) pieces of legacy code into the overall "shape" of the new platform architecture, while still remaining in the legacy world, as legacy plugins, consuming legacy services.

A module is done with Phase I when all of its code has been relocated to the appropriate plugin, with downstream imports for the module being updated to consume it from its new location.

[elasticmachine]

Pinging @elastic/kibana-app-arch

[joshdover]

Last we talked about this issue, I believe we decided this module is not needed in the New Platform. It's behaviors should be replaced by either React Router for syncing URL state, via plugin contracts for global state like timepicker & filter manager, or the "state containers" in the kibana_utils plugin.

Is there anything else I'm missing that this is still needed for that isn't already covered?

[lukeelmers]

I will go ahead and close this one for now, as it has been duplicated by #44151 which has more detail on state management in the NP in general.

There are still questions to figure out, but generally yes -- the idea is that we don't need an exact equivalent of this in the NP. Instead we can offer utilities to help plugins manage state on their own.