Kibana dependency update procedure

[markov00]

The elastic-charts dependency in Kibana needs to be updated every X weeks/release following is the draft procedure.

Kibana dependency upgrade procedure

Kibana use RenovateBot to automatically create a PRs with the updated dependencies. We should use the bot PRs and push any commits that are required to solve any breaking changes issue (the bot will stop updating the PR with a newer version if you pushed a commit to that branch).

1. Check if the RenovateBot has already created a PR for the newer version here: renovate bot dependencies GH issue or here list of all PRs. If you don't find the PR, create one from scratch using this PR as an example. Please use the following title if we are just upgrading the library:
   Update dependency @elastic/charts to v19.0.0
   If the upgrade fixes a specific issue, then you can use a more specific title like:
   [TSVB] Fix wrongly display stacked as percentage charts

2. Apply, at least, the following labels and any other that may apply: Feature:ElasticCharts, dependencies, release_note:skip

3. Check the PR description, in particular, the Release Notes to see if everything is correctly reported (I've seen sometimes issues with the Release Notes not correctly picked up by the bot). Release notes should be germane to fixes to features related to Kibana, not @elastic/charts.

4. Add a link of this issue in the PR description with the following:

[@elastic/charts update procedure](https://github.com/elastic/elastic-charts/issues/583)

4. Fixing failures and breaking changes:

   1. if we are upgrading to a minor or a patch version and failures appear on the CI, please open an issue in the elastic-chart repo reporting that failure if directly related to elastic-charts. We should strictly follow the semantic versioning, so if on a minor or a patch release there are issues with the code, maybe something is slipped through the public API and we didn't publish correctly a breaking change release.
   2. If we are upgrading a major release it's probable that we are getting at least one failure on the CI. Check the failure and it's relation with elastic-charts and try to fix them on the PR branch.
   3. A failure maybe not be directly picked by the CI due to missing tests. A manual check on every breaking change is always required. The easiest way is to manually check the current implementation details on the Kibana repo where the elastic-chart library is used: search through the repo for every library import from '@elastic/charts and check the code against the breaking changes of the library (i.e. Lens, dashboard, TSVB, etc.).
      NOTE: there can be existing code that uses elastic-charts in a js code where you will never get type errors if something is changed. So please check also those codes manually to see if you can spot non-detected breaking changes (here for example ml is using our typing to render a similar tooltip, but the code that generate the tooltip data is under pure js files elastic/kibana@ec82779) . CSS breaking changes, like changing a classname can also slip through the CI. Check the library for any of these breaking changes and apply them to Kibana.
   4. The PR will automatically request the review of every team involved in the changes made, but you can also ping directly the author of the chart implementation.
   5. If the breaking changes are relative to a visual change, like a different look-and-feel, a different default value on the APIs, etc, please check if the visual change also applies on each chart implementation, describe the visual change on the PR, and ping each chart consumer involved asking to double-check the change, revert that change on the Kibana code if requested. (note: we should write a quick guide on how to test each chart implementation ourselves on a running Kibana instance. Actually it's not that easy due to the need for a different type of dataset on each specific case, but we should find an easy way to check that)
   6. Merge the PR only when we got a review of each team involved.
   7. Backport the PR if necessary following the backporting guide. Do not backport a major version into a maintenance branch, just merge it into master and the previous minor version

5. Update the following table with the current dependency version merged in Kibana.

Kibana Version	on package.json	on yarn
v7.2.0 yarn.lock	^4.2.6	4.2.6
v7.2.1 yarn.lock	^4.2.6	4.2.6
v7.3.0 yarn.lock	^7.0.1	7.0.1
v7.3.1 yarn.lock	^7.0.1	7.0.1
v7.3.2 yarn.lock	^7.0.1	7.0.1
v7.4.0 yarn.lock	^12.0.2	12.0.2
v7.4.1 yarn.lock	^12.0.2	12.0.2
v7.4.2 yarn.lock	^12.0.2	12.0.2
v7.5.0 yarn.lock	^13.5.12	13.5.12
v7.5.1 yarn.lock	^13.5.12	13.5.12
v7.5.2 yarn.lock	~13.5.13	13.5.13
v7.6.0 yarn.lock	^16.1.0	16.1.0
v7.6.1 yarn.lock	^16.1.3	16.1.3
v7.6.2 yarn.lock	^16.1.3	16.1.3
7.7 yarn.lock	^18.1.1	18.2.0
7.x yarn.lock	18.4.1	18.4.1
master yarn.lock	18.4.1	18.4.1

[markov00]

Moved to the wiki page