Improve breaking changes/deprecation formatting

[marefr]

It's quite hard to overview all of the breaking changes, e.g. v9.0.0-beta2 release notes.

Suggesting a formatting like this:

#### <PR title> (#<PR number/link>)
<!-- breaking change notice -->

Would create something like below using some of the breaking changes from v9.0.0-beta2 release notes as an example:

---

Breaking changes

AuthProxy: Remove deprecated ldap_sync_ttl setting (#49902)

Drop support for deprecated setting ldap_sync_ttl under [auth.proxy]
Only sync_ttl will work from now on

UI/Card: Remove deprecated props (#49885)

Removes support for deprecated heading and description props. Moving forward, the Card.Heading and Card.Description components should be used.

UI/Button: Remove deprecated "link" variant (#49843)

Removes the deprecated link variant from the Button component.
To migrate, replace any usage of variant="link" with fill="text".

Toolkit: Bump dependencies (#47826)

Plugins using custom Webpack configs could potentially break due to the changes between webpack@4 and webpack@5. Please refer to the official migration guide for assistance.

Webpack 5 does not include polyfills for node.js core modules by default (e.g. buffer, stream, os). This can result in failed builds for plugins. If polyfills are required it is recommended to create a custom webpack config in the root of the plugin repo and add the required fallbacks:

// webpack.config.js

module.exports.getWebpackConfig = (config, options) => ({
  ...config,
  resolve: {
    ...config.resolve,
    fallback: {
      os: require.resolve('os-browserify/browser'),
      stream: require.resolve('stream-browserify'),
      timers: require.resolve('timers-browserify'),
    },
  },
});

Please refer to the webpack build error messages or the official migration guide for assistance with fallbacks.

BackendSrv: Throw an error when fetching an invalid JSON #47493

We have changed the internals of backendSrv.fetch() to throw an error when the response is an incorrect JSON.

// PREVIOUSLY: this was returning with an empty object {} - in case the response is an invalid JSON
return await getBackendSrv().post(`${API_ROOT}/${id}/install`);

// AFTER THIS CHANGE: the following will throw an error - in case the response is an invalid JSON
return await getBackendSrv().post(`${API_ROOT}/${id}/install`);

When is the response handled as JSON?

• If the response has the "Content-Type: application/json" header, OR
• If the backendSrv options (BackendSrvRequest) specify the response as JSON: { responseType: 'json' }

How does it work after this change?

• In case it is recognised as a JSON response and the response is empty, it returns an empty object {}
• In case it is recognised as a JSON response and it has formatting errors, it throws an error

How to migrate?
Make sure to handle possible errors on the callsite where using backendSrv.fetch() (or any other backendSrv methods).

[GrafanaWriter]

I think this is a really useful section to build and I like the format. Is it possible to put this information into a section of the What's New document?

The reason I'm asking is that we currently maintain three separate documents - changelog, release notes, and What's New. Reviewing our Google Analytics, the release notes receive almost no traffic and the What's New document both receives traffic and high levels of engagement (time on page).

[marefr]

Is it possible to put this information into a section of the What's New document? Nothing automatic in place at the moment and not sure how easy that would be. Feels like a new issue (somewhere else perhaps rethinking the whole changelog, release notes, and What's New workflow/process?)