Add solution property to Spaces

[legrego]

The definition of a Space should be updated to include a solution property.
This property should only be defined for the stateful offering. It is not applicable to serverless.

Within a stateful deployment, this property is required for all new Spaces, and optional for all existing spaces. This enforcement can happen in code and should not require a Saved Objects migration.

Valid values for the solution property:

• undefined (to accommodate all existing spaces)
• 'security'
• 'observability'
• 'search'
• 'classic'

Requirements

1. The Create space API should be updated to accept a solution property.
   1a) This property is forbidden for serverless projects.
   1b) This property is required to be defined for stateful deployments (key and value CANNOT be undefined). To facilitate iterative development, we may want to ship this as an optional property until all of the workstreams are complete, and create a followup PR which changes this from optional to required.
2. The Update space API should be updated to accept a solution property.
   2a) This property is forbidden for serverless projects.
   2b) This property is optional for stateful deployments (key and value CAN be undefined). To facilitate iterative development, we may want to ship this as an optional property until all of the workstreams are complete, and create a followup PR which changes this from optional to required.
   2b1) When the solution property is provided, the value cannot be undefined. This prevents a space from unsetting their solution.
   2b2) When the solution property is not provided, the value should not be modified.
3. The Get space API should be updated to return the solution property of the requested space for stateful deployments. The property should not be returned for serverless projects.
4. The Get all spaces API should be updated to return the solution property for all spaces in the payload. The property should not be returned for serverless projects.

Important

These public APIs are powered by the SpacesClient, which is exposed by the spaces plugin contract. We should make every effort to enforce these rules within the SpacesClient so that other plugins aren't able to bypass these restrictions.

[elasticmachine]

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

[legrego]

@azasypkin do you have a preference/recommendation for how we control whether or not the solution property is permitted? The requirements I wrote are framed as "stateful vs serverless", but I know we've tried try not to litter our code with those checks. Similar to what we did for xpack.spaces.allowFeatureVisibility, would you like to see this implemented as a yml setting that we control the value of based on deployment type?

[azasypkin]

Similar to what we did for xpack.spaces.allowFeatureVisibility, would you like to see this implemented as a yml setting that we control the value of based on deployment type?

Thanks for the ping. Yeah, I think having a deployment-type-specific configuration property (via offeringBasedSchema) would probably be the most straightforward and least controversial solution here. It's also marked as the second best approach after a serverless-specific plugin in our Changing plugin behavior in serverless platform recommendations.

[elena-shostak]

@azasypkin @legrego I see that we don't register create/update/delete routes for spaces in serverless.
Do we still need a configuration property then? Seems the routes itself are just not registered, except GET ones.
Will we use configuration property then to only strip out support field from GET endpoints?

[legrego]

@elena-shostak we will enable these routes for serverless as soon as the customer roles work is completed. cc @jeramysoucy