Different Deprecation Categorization

[pgomulka]

At the time of the 8.0 upgrade we want to differentiate these in two buckets:

Critical deprecations: These are features that are going away when they move to 8 and the user needs to take action before upgrading.
Informational deprecations: These are features that have been deprecated but aren't actually removed in 8.0. While we would like the user to stop using them now, it's not critical they do so before upgrading.

Currently all deprecation log entries are categorised as DEPRECATION. In order to classify these in the UI we would like by default all current deprecations to be level "CRITICAL", but offer teams the option to mark specific deprecations as "WARN". For example if the distributed team deprecated a feature but haven't removed it in 8.0, they could choose to go back to the deprecation log statement and change it to be an INFO level deprecation. By default if teams did nothing any existing deprecations would be marked as CRITICAL.

[elasticmachine]

Pinging @elastic/es-core-infra (Team:Core/Infra)

[elasticmachine]

Pinging @elastic/es-core-features (Team:Core/Features)

[pgomulka]

Should we also make this consistent with levels of deprecations in Deprecation Info API?

elasticsearch/x-pack/plugin/deprecation/src/main/java/org/elasticsearch/xpack/deprecation/DeprecationIssue.java

Line 37 in dda172e

CRITICAL

we define two levels there

 /**
         * Resolving this issue is advised but not required to upgrade. There may be undesired changes in behavior unless this issue is
         * resolved before upgrading.
         */
        WARNING,
        /**
         * This issue must be resolved to upgrade. Failures will occur unless this is resolved before upgrading.
         */
        CRITICAL
        ;