Expose deprecation indices to upgrade assistant

[jasontedor]

This issue is contingent on #46106. See that issue for most of the context.

If we do decide to proceed with the proposal in that issue in one form or another, we then need to consider how to expose such deprecation indices to the upgrade assistant. Do we want to treat exposing them as part of the /_migration/deprecations endpoint, or do we want the upgrade assistant to access the deprecation indices directly (through an API on top of them as part of being system indices)?

[elasticmachine]

Pinging @elastic/es-core-features

[pgomulka]

II think it would be great if there was one way to access deprecation information. Not only because it would be useful from upgrade assistant, but to also make it easier to upgrade for users who don't use kibana (I think there was a question about this during last stack-upgrade sync)
As suggested here to either wrap deprecation logs within /_migration/deprecations or refactor current DeprecationInfoAction so that deprecation issues could be accessed the same way as deprecation logs.

Deprecation info checks are using cluster, node and index settings and have to be triggered 'on demand' - that means we won't be able to avoid that call from upgrade assistant (or someone doing this from console). Because of this I appears to me that the first suggested option (wrapping logs as a result form `/_migration/deprecation/') would be more preferable.

[jakelandis]

Discussed this issue today and a few things have changed since initially logged.

• The deprecation logs are now (optionally) indexed
• The deprecation logs are indexed to a data stream using the ingest management 3-part-pattern.
• There are tentative plans to also index other stack products (kibana, beats, etc.) using the same strategy.

Given that one of motivating factors was that these were going to be system indices, but are now data streams (and we don't have system or hidden data streams) the need for a dedicated 'read' end point is not necessary. Also with the data stream and the new indexing strategy a 'write` endpoint is also not needed, and likely not desirable since the new indexing strategy with ECS fields should be sufficient and familiar way to handle these types of logs.

Finally we discussed that a dedicated read end point only allows for a curated experience could come at the expense of being able to use standard tooling such as Kibana visualizations or alerts based on aggregations which some more advanced users may want to help track or monitor their usage of deprecated components. There are still plans to for a curated experience with these logs, but those discussions are not finalized and a dedicated endpoint is likely unnecessary.