Ensure deprecation documentationUrl's point to correct doc branch

[watson]

This was made possible via PR #113600.

This PR does not do anything about the documenationUrl usage in the following files as they do not currently have access to ConfigDeprecationContext:

• src/plugins/data_views/server/deprecations/scripted_fields.ts
• x-pack/plugins/apm/server/deprecations/index.ts
• x-pack/plugins/maps/server/index.ts
• x-pack/plugins/reporting/server/deprecations/reporting_role.ts

This PR will not be backported to the 7.x branch. In regards to deprecation messages there's too many differences between master and 7.x to warrant a single PR to master that's then backported to 7.x. I've made another PR specifically for 7.x: #114263.

[azasypkin]

Code LGTM

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: fa808f5
• Storybooks Preview

Metrics [docs]

✅ unchanged

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @watson

[tsullivan]

This PR does not do anything about the documenationUrl usage in the following files as they do not currently have access to ConfigDeprecationContext:

Hi @watson and @pgayvallet, it looks like the common thing with all the files that do not have access to ConfigDeprecationContext is that those deprecations are not declared within a PluginConfigDescriptor object. Instead, the deprecations are declared with core.deprecations.registerDeprecations.

Am I understanding correctly? Is there a plan to expose ConfigDeprecationContext for deprecations registered with core.deprecations.registerDeprecations?

[pgayvallet]

it looks like the common thing with all the files that do not have access to ConfigDeprecationContext is that those deprecations are not declared within a PluginConfigDescriptor object. Instead, the deprecations are declared with core.deprecations.registerDeprecations.

Yea, the common thing is that they're not registered directly using the plugin's configuration descriptor (PluginConfigDescriptor), and instead are registered via core.deprecations.registerDeprecations during their respective plugin's setup lifecycle.

Given that, it's possible for the deprecation owner to leverage the PluginInitializerContext passed down to plugins to access the branch via initContext.env.packageInfo.branch, therefor this was not considered a blocker as it was for pure config deprecations.

Is there a plan to expose ConfigDeprecationContext for deprecations registered with core.deprecations.registerDeprecations?

That's #114065. But it will very likely not be done for 7.16