Make config id independent of Kibana version

[legrego]

This PR introduces a version field to the config Saved Object. This is used to store the version of Kibana for which that configuration is valid. Previously, this information was stored in the config document's ID.

Motivation

Having the Kibana version stored as the document id prevents us from having multiple configuration objects for the same version of Kibana. While this historically hasn't been a limitation, the upcoming Spaces project will need to be able to store a separate config object for each Space users create.

Implementation

The default behavior is very similar to how it currently works: the config id will be the Kibana Version.

The Spaces plugin (or potentially another consumer) can choose to augment the ID by calling request.setUiSettingsIdSuffix(). When an ID Suffix is set, the UI Settings Service will append the suffix to the default identifier.

While the ID will still contain the Kibana version (for readability), it will no longer be the authoritive source for this information. The new version field is instead used to determine this.

example:

Default ID: 7.0.0
ID after calling request.setUiSettingsIdSuffix('my-suffix'): 7.0.0:my-suffix

This is a rather naive approach, so I'm more than open to suggestions here.
I also want to make sure the approach we take here can translate easily enough to the new platform.

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💔 Build Failed

• continuous-integration/kibana-ci/pull-request

[elasticmachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request

[legrego]

Hey @elastic/kibana-platform, would you mind weighing in on this PR? As I noted above, this is a rather simplistic approach, so let me know if you have any ideas for a more holistic solution.

cc @kobelb

[legrego]

Closing.
Spencer suggested a much better approach -- we will instead append the space id to the saved object id at the SavedObjectsClient level. We will do this for all Saved Object types, which eliminates the one-off approach that this PR introduced.