Remove dependency on doc versions

[spalger]

See elastic/elasticsearch#38254

Using the version parameter to implement optimistic concurrency is not going to be supported in 7.0, so we need to replace our usage of document version with the new _seq_no and _primary_term parameters. These fields are returned in the same way that _version was returned on all read/write requests except for search, where it needs to be requested by sending seq_no_primary_term: true in the body of the search request. These parameters are sent back to Elasticsearch on write requests with the if_seq_no and if_primary_term parameters, and are functionally equivalent to sending a version in a write request before elastic/elasticsearch#38254.

To make these updates I searched the code base for uses of a version and _version, then triaged each usage, so I'm fairly confident that I got everything but it's possible something slipped through the cracks, so if you know of any usage of the document version field please help me out by double checking that I converted it.

• Saved Objects: @elastic/kibana-platform, @elastic/es-security - for BWC and ergonomics the version provided by the Saved Objects client/API was not removed, it was converted from a number to a string whose value is base64(json([_seq_no, _primary_term])). This allows the Saved Objects API and its consumers to remain mostly unmodified, as long as the underlying value in the version field is irrelevant. This was the case for all usages in Kibana, only thing that needed updating was tests and TS types.

• Reporting/esqueue: @joelgriffith, @tsullivan - the version parameter was used here specifically for implementing optimistic concurrency, and since its usage was contained within the esqueue module I just updated it to use the new _seq_no and _primary_term fields.

• Task Manager: @tsullivan @njd5475 - Like esqueue this module uses version for optimistic concurrency but the usage is contained with the module so I just updated it to use, store, and request the _seq_no and _primary_term fields.

• ML: @elastic/ml-ui - Best I could tell the only "version" in the ML code refers to the stack version, 077245f

• Beats CM: @elastic/beats - Looks like the references to _version in the code is only in the types but not in the code itself. I updated the types to use _seq_no and _primary_term, and their camelCase equivalents where appropriate. I did find a method that used one of the types referencing version but when investigating its usage it seemed the only consumer of that method was itself so i removed it. 52d890f

• Spaces (tests): @elastic/kibana-security - The spaces test helpers use saved objects with versions in a number of places, so I updated them to use the new string versions where the version was predictable, and removed the assertion on version where it wasn't. We test the version in the saved objects code so this should be fine.

[elasticmachine]

💚 Build Succeeded

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

[mikecote]

LGTM 👍

[njd5475]

LGTM

[elasticmachine]

💚 Build Succeeded

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

[walterra]

You're right we haven't been using version in ML in that context, LGTM!

[sorenlouv]

@spalger This change caused some things to go awry with APM Getting Started flow (#30651). But not to worry! :) We have a PR ready with a fix #30796. Can you verify it is the correct approach?

Btw. Is there something we could have done to avoid this? Eg. add a test or somehow made it clear we depend on the saved objects API?

[spalger]

@sqren best option would be to have it covered by a functional test, I'm kind of surprised that I missed that.