Move and refactor x-pack plugin code for Security and Spaces

[jportner]

The Security team maintains several plugins:

• /src/plugins/security_oss
• /src/plugins/spaces_oss
• /x-pack/plugins/encrypted_saved_objects
• /x-pack/plugins/security
• /x-pack/plugins/spaces

Now that we are only shipping the Default distribution, we can refactor consumers to get rid of the security_oss/spaces_oss plugins. Optionally, we may move the existing plugins from the x-pack directory to the regular plugin directory, though this would entail changing the license of existing x-pack code (adding SSPL)

[elasticmachine]

Pinging @elastic/kibana-security (Team:Security)

[thomasneirynck]

thx for raising this issue.

There is an existing use-case that would greatly benefit from this refactor.

The Vega plugin (formerly OSS, now Elastic v2/SSPL) uses EMS. To enable Vega to use on-prem deployments of EMS (#89304), the user needs to have an enterprise license. It would be nice if we can perform this license-check client-side (just like that same check in the x-pack Maps-app).

In order to do this license-check, plugins need to depend on the licensing-plugin. It appears Vega-plugin cannot directly add a dependency on the licensing-plugin (because this would bundle code from the licensing-plugin inside the Vega-bundle). The work-around would require the reintroduction of the same kind of "enhancer"-plugin. Similar "enhancer plugins" were used to distinguish between OSS and Basic in "pre-license change" era, to "upgrade" functionality of the OSS-plugins. It would be great if this sort of work-around would no longer be needed.

[jportner]

CC @kobelb

[jportner]

Reopening this, still need to get rid of securityOss plugin

[jportner]

In attempting to get rid of the securityOss plugin, I noticed a couple of hiccups:

1. This adds a direct dependency from share to security, creating a new circular dependency: data -> share -> security -> data
   The share plugin is one of the few required by data, and tons of other plugins require data. So I think we'll need to invert the dependency between security and share.
2. We would also need to deprecate the security.showInsecureClusterWarning setting, renaming it to xpack.security.showInsecureClusterWarning