Initial framework for data plugin. - #34350

We've had some conversations around the idea of creating a new platform plugin that is owned by @elastic/kibana-app-arch and houses any services that apps might rely on for retrieving & managing data in kibana:

• interpreter & expressions
• courier & querying infrastructure
• index patterns
• filter bar, query bar, time picker (and possibly the corresponding UIs too, TBD)

At the same time, we are trying to sort out the best path forward for consolidating items from ui/public into their respective locations.

The idea here is pretty straightforward:

1. We create a legacy plugin in the shape of the data plugin mentioned above
2. This plugin will have services created for each item we think it should own
3. For now, services will simply re-export items from their existing locations (whether they be in plugins/ or ui/public)
4. Downstream imports can be updated across kibana to point to the data plugin
5. Once that's complete, we can then actually move items into the plugin without breaking anything

Here's an example of what importing would look like:

// in the new platform, the below import will be removed as `data` will already be
// getting passed in to the service
import * as data from 'plugins/data';

// using functions
const { IndexPatternsProvider } = data.indexPatterns;
const indexPatterns = IndexPatternsProvider(whatever);

// using constants
const { INDEX_PATTERN_ILLEGAL_CHARACTERS } = data.indexPatterns.constants;
console.log(`Using constants: ${INDEX_PATTERN_ILLEGAL_CHARACTERS}`);

// using ui componenets
const { IndexPatternSelect } = data.indexPatterns.ui;
<IndexPatternSelect />

This has the benefit of giving the service the general shape of the new platform, where everything will be injected in the plugin's setup() method as data.

For unstable items, or things we know will have an API changed in the near future, we could consider adding a legacy namespace so you would import like:

import * as data from 'plugins/data';

data.indexPatterns.legacy.someLegacyFunction();

And then move items out of legacy when we sort out a longer-term API.

Still TBD:

• Conventions for exporting types
  • Core has established some conventions for exporting each service's Setup types, which I think we should mirror over time and I've tried to mimic here
  • For miscellaneous types that already exist and need to be exported, I'm explicitly adding those to the returned value of setup within each service for now, inside a types object
• Handling for server stuff (this is so far focused on client stuff since we're trying to use it as a means of eliminating ui/public)
  • Since there's not too much server stuff we need to add initially, I won't worry too much about this yet.
• What to do with testing utilities like mocks & fixtures.
  • With app arch plugins specifically, I think we should model this after core and provide first-class mocks for each service, since app developers will be building on top of our services