Gracefully handle deprecated core API's

[TinaHeiligers]

A number of core API's were deprecated during the 7.x series and we need to come up with a plan to eventually remove them.
Before we can do that, in the interests of backward compatibility, we need to ensure that the deprecated API's are not being used.

In #77997, we identified the following API's that need to be tracked and monitored for usage:

track and Monitor:

In src/core/server/*:

• httpServiceSetup.auth (use HttpServiceStart.auth instead) (Remove deprecated & unused HttpServiceSetup.auth #127056)
• IRenderOptions.vars apparently should have been removed with ui_render_mixin.

In src/core/public/*:

• CoreSetup.injectedMetadata (should have been removed when Add config value support in frontend to New Platform #41990 was handled with Expose whitelisted config values to client-side plugin #50641) TL;DR: used to share config between server and client in plugins. Replaced with PluginInitializerContext
• CoreStart.injectedMetadata (should have been removed when Add config value support in frontend to New Platform #41990 was handled with Expose whitelisted config values to client-side plugin #50641) TL;DR: used to share config between server and client in plugins. Replaced with PluginInitializerContext

Scope:

• Identify where the APIs are used
• Remove 'em (or create a task for codeowners to remove)

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[TinaHeiligers]

Audit results:

httpServiceSetup.auth doesn’t appear to be used directly but we need to clean up the types:
HttpServiceStart and HttpServiceSetup are still coupled so removing auth from the setup contract type will also remove it from start.

IRenderOptions.vars is used to [add RUM config] (https://github.com/elastic/kibana/blob/main/src/core/server/http_resources/http_resources_service.ts#L98-L100) added in (#92784)

CoreSetup.injectedMetadata and CoreStart.injectedMetadata are still being used extensively throughout core (also in bootstrap) and the following plugins:

• data_views,
• vis_types/vega,
• fleet,
• security,
• monitoring

Since these deprecations don't have a fixed date for removal (yet), we need to consider if it's worth following through on the deprecations and eventually sunset them or keep the support and remove the deprecation.

[lukeelmers]

After discussing, we decided the scope here will be:

• adding @removeBy to each of the APIs so we can get a report of who is using the deprecated APIs in the docs (see Remove unreferenced deprecated APIs #121823)
• create a list of any items that aren't explicitly marked as deprecated yet so we can decide whether to deprecate them

[afharo]

From #121956, we've identified 2 additional APIs that are deprecated but still used. Although TS wouldn't catch it for different reasons:

IHttpFetchError.res

Attempt to remove it: #127059
Not removed because it's actually used (refer to the PR from above for the list). However, TS doesn't realize because it's used in the error handling of a few try/catch, and TS treats the err object in the catch as any.

PluginManifest.extraPublicDirs

It's used by @kbn/optimizer. It was created as deprecated straight away because the intention is to replace it with something else in the future. However, at the moment, there are no short-term plans to replace it.

[afharo]

I created #127744 to:

1. add the @removeBy tags to the deprecated but still used, and there's an alternative
2. add the link to the issue that should be tackled to provide an alternative so we can set the @removeBy label
3. Create issues for the unused APIs to track their removal