PoC - independent solution repo structure

[lukeelmers]

Definitely don't merge this

This is a proof-of-concept which explores what it would look like to make solutions more independent by restructuring the repo in a way that enforces new plugin-level boundaries. These boundaries prevent solution plugins from having dependencies on each other, forcing any shared dependencies to live in the platform:

These boundaries are enforced by the directory structure of the repo. For illustrative purposes, this is the directory structure used in this PR (the final structure would likely be a bit different):

.
├── src
│   └── platform
│       └── internal // not available to plugins outside of platform
└── x-pack
    ├── observability
    ├── platform
    │   └── internal // not available to plugins outside of platform
    ├── search
    └── security

Plugins are only allowed to have dependencies on plugins which exist in the platform directory, so for example, a plugin in security could not depend on another in observability.

Plugins which are leftover in src/plugins and x-pack/plugins were identified as problematic because they don't currently adhere to these restrictions and would need to be refactored or have bits relocated to platform. These include:

ai_assistant_management/observability
x-pack/enterprise_search
x-pack/index_lifecycle_management
x-pack/ingest_pipelines
x-pack/monitoring_collection
x-pack/observability_solution/infra
x-pack/observability_solution/logs_shared
x-pack/osquery
x-pack/upgrade_assistant

The enforcement logic in 7077867 may not be how we'd actually implement this in production, especially if we were looking to add similar logic to packages... in that case it would be worth considering strategies for making this more generalized.

Follow-up tasks not done here

• move src/core -> src/platform/core (requires a lot of changes to hard-coded paths)
• split up packages & evaluate options for enforcement (kbn_references?)
• look for easier ways to update paths in config files (can this be automated without too much effort?)
• split up global eslint config and relocate pieces in solution directories
• split up FTR configs and relocate to relevant solution directories

[kibana-ci]

💔 Build Failed

• Buildkite Build
• Commit: 1f290a9bed417d226dd887f574703eafad085d79
• Interpreting CI Failures

Failed CI Steps

• Quick Checks

History

• 💔 Build #209990 failed 193c5b5afb6a8831f433cf17ee3bd86623792195
• 💔 Build #201270 failed a23cf7216044e9ee44803d3a98da8c002cc7dff7
• 💔 Build #201173 failed 07821f7698526d8379ddc7c04f508a70529c27ce
• 💔 Build #200964 failed da982d779495193d64595fd4415284f78f0929ff
• 💔 Build #200697 failed 8e665d023b6fe10cd89d70863d9e19cf989f5167

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream