…tic#81039)

Previously we intended that 8.x ML would only accept model snapshots
created in version 7.0.0 or above. However, due to a bug
(elastic/ml-cpp#1545) it's not possible to distinguish model
snapshots created in versions 6.4.0-7.9.3 inclusive. Therefore,
to be sure of meeting the stated policy of accepting model snapshots
created in 7.0.0 or above ML will have to really accept those
labelled as 6.4.0 or above.

Fixes elastic#81011

…) (#81048)

Previously we intended that 8.x ML would only accept model snapshots
created in version 7.0.0 or above. However, due to a bug
(elastic/ml-cpp#1545) it's not possible to distinguish model
snapshots created in versions 6.4.0-7.9.3 inclusive. Therefore,
to be sure of meeting the stated policy of accepting model snapshots
created in 7.0.0 or above ML will have to really accept those
labelled as 6.4.0 or above.

Fixes #81011

This is a followup to elastic#81039.

The same requirement to tolerate model snapshots back to 6.4.0
that applies to the job opening code also applies to the deprecation
checker. Again, we tell the user that 7.0.0 is the model snapshot
version we support, but we actually have to support versions going
back to 6.4.0 because we didn't update the constant in the C++ in
7.0.0.

Additionally, the wording of the ML deprecation messages is very
slightly updated. The messages are different in the 7.16 branch,
where they were updated by elastic#79387. This wording is copied forward
to master, but with the tiny change that "Snapshot" is changed to
"Model snapshot" in one place. This should make it clearer for
users that we're talking about ML model snapshots and not cluster
snapshots (which are completely different things). Another reason
to change the wording is that the UI is looking for the pattern
/[Mm]odel snapshot/ to decide when to display the "Fix" button for
upgrading ML model snapshots - see elastic/kibana#119745.

…#81060)

This is a followup to #81039.

The same requirement to tolerate model snapshots back to 6.4.0
that applies to the job opening code also applies to the deprecation
checker. Again, we tell the user that 7.0.0 is the model snapshot
version we support, but we actually have to support versions going
back to 6.4.0 because we didn't update the constant in the C++ in
7.0.0.

Additionally, the wording of the ML deprecation messages is very
slightly updated. The messages are different in the 7.16 branch,
where they were updated by #79387. This wording is copied forward
to master, but with the tiny change that "Snapshot" is changed to
"Model snapshot" in one place. This should make it clearer for
users that we're talking about ML model snapshots and not cluster
snapshots (which are completely different things). Another reason
to change the wording is that the UI is looking for the pattern
/[Mm]odel snapshot/ to decide when to display the "Fix" button for
upgrading ML model snapshots - see elastic/kibana#119745.

…elastic#81060)

This is a followup to elastic#81039.

The same requirement to tolerate model snapshots back to 6.4.0
that applies to the job opening code also applies to the deprecation
checker. Again, we tell the user that 7.0.0 is the model snapshot
version we support, but we actually have to support versions going
back to 6.4.0 because we didn't update the constant in the C++ in
7.0.0.

Additionally, the wording of the ML deprecation messages is very
slightly updated. The messages are different in the 7.16 branch,
where they were updated by elastic#79387. This wording is copied forward
to master, but with the tiny change that "Snapshot" is changed to
"Model snapshot" in one place. This should make it clearer for
users that we're talking about ML model snapshots and not cluster
snapshots (which are completely different things). Another reason
to change the wording is that the UI is looking for the pattern
/[Mm]odel snapshot/ to decide when to display the "Fix" button for
upgrading ML model snapshots - see elastic/kibana#119745.

…checker

This is a followup to elastic#81039.

The same requirement to tolerate model snapshots back to 6.4.0
that applies to the job opening code also applies to the deprecation
checker. Again, we tell the user that 7.0.0 is the model snapshot
version we support, but we actually have to support versions going
back to 6.4.0 because we didn't update the constant in the C++ in
7.0.0.

Additionally, the wording of the ML deprecation messages is very
slightly updated. The messages are different in the 7.16 branch,
where they were updated by elastic#79387. This wording is copied forward
to master, but with the tiny change that "Snapshot" is changed to
"Model snapshot" in one place. This should make it clearer for
users that we're talking about ML model snapshots and not cluster
snapshots (which are completely different things). Another reason
to change the wording is that the UI is looking for the pattern
/[Mm]odel snapshot/ to decide when to display the "Fix" button for
upgrading ML model snapshots - see elastic/kibana#119745.

Backport of elastic#81060

…#81060) (#81101)

This is a followup to #81039.

The same requirement to tolerate model snapshots back to 6.4.0
that applies to the job opening code also applies to the deprecation
checker. Again, we tell the user that 7.0.0 is the model snapshot
version we support, but we actually have to support versions going
back to 6.4.0 because we didn't update the constant in the C++ in
7.0.0.

Additionally, the wording of the ML deprecation messages is very
slightly updated. The messages are different in the 7.16 branch,
where they were updated by #79387. This wording is copied forward
to master, but with the tiny change that "Snapshot" is changed to
"Model snapshot" in one place. This should make it clearer for
users that we're talking about ML model snapshots and not cluster
snapshots (which are completely different things). Another reason
to change the wording is that the UI is looking for the pattern
/[Mm]odel snapshot/ to decide when to display the "Fix" button for
upgrading ML model snapshots - see elastic/kibana#119745.

…checker (#81105)

This is a followup to #81039.

The same requirement to tolerate model snapshots back to 6.4.0
that applies to the job opening code also applies to the deprecation
checker. Again, we tell the user that 7.0.0 is the model snapshot
version we support, but we actually have to support versions going
back to 6.4.0 because we didn't update the constant in the C++ in
7.0.0.

Additionally, the wording of the ML deprecation messages is very
slightly updated. The messages are different in the 7.16 branch,
where they were updated by #79387. This wording is copied forward
to master, but with the tiny change that "Snapshot" is changed to
"Model snapshot" in one place. This should make it clearer for
users that we're talking about ML model snapshots and not cluster
snapshots (which are completely different things). Another reason
to change the wording is that the UI is looking for the pattern
/[Mm]odel snapshot/ to decide when to display the "Fix" button for
upgrading ML model snapshots - see elastic/kibana#119745.

Backport of #81060

… Learning jobs (#118549)

Since in 9.0 we don't need to support snapshots prior to 7.17, we can simplify the changes made in #81039 and re-introduce a single contant to manage the minimum supported snapshot version.