Callout breaking changes on integration upgrade

[MichelLosier]

Summary

Resolves: #187481

• Adds a warning callout about breaking changes in the changelog for integration upgrades
  • Callout lists breaking changes and provides PR links
  • Includes "I understand" checkbox that must be clicked before upgrade is allowed
    • Upgrade button is disabled until this is confirmed

Local testing

• Go to the integrations view
• Find and click the docker integration
• Change the version of the integration in the url path to 1.2.0
  • Example: <localhost:port>/kibana/app/integrations/detail/docker-1.2.0/overview
• Click the "Add Docker Metrics" CTA
• After install go to the Docker integration settings view

To do

• UX feedback
• Apply i18n and Formatted (pluralization) to text
• Tests

Checklist

Check the PR satisfies following conditions.

Reviewers should verify this PR satisfies this list as well.

• Any text added follows EUI's writing guidelines, uses sentence case text and includes i18n support
• Documentation was added for features that require explanation or tutorials
• Unit or functional tests were updated or added to match the most common scenarios
• If a plugin configuration key changed, check if it needs to be allowlisted in the cloud and added to the docker list
• This was checked for breaking HTTP API changes, and any breaking changes have been approved by the breaking-change committee. The release_note:breaking label should be applied in these situations.
• Flaky Test Runner was used on any tests changed
• The PR description includes the appropriate Release Notes section, and the correct release_note:* label is applied per the guidelines

Identify risks

Does this PR introduce any risks? For example, consider risks like hard to test bugs, performance regression, potential of data loss.

Describe the risk, its severity, and mitigation for each identified risk. Invite stakeholders and evaluate how to proceed before merging.

• See some risk examples
• ...

[elasticmachine]

🤖 Jobs for this PR can be triggered through checkboxes. 🚧

ℹ️ To trigger the CI, please tick the checkbox below 👇

• Click to trigger kibana-pull-request for this PR!
• Click to trigger kibana-deploy-project-from-pr for this PR!
• Click to trigger kibana-deploy-cloud-from-pr for this PR!

[MichelLosier]

Here is a first pass implementation that adds a separate breaking change warning callout:

Having the upgrade callout, and the breaking change callout be the same kind of "warning" style feels like too much attention grabbing here.

Alternative considerations:

• Combine the breaking change messaging into the single "New version available" callout.
  • The breaking changes portion feels like it needs its own prominence if in a shared callout, maybe give it its own sub-heading in the callout?
• The existing "New version available" callout could be better suited with a "primary" (blue) info callout, and maybe a "cheer" icon to announce it (see example below). Separately the breaking change callout follows the "warning" style due to the risk.
  • That said, I could also read the "New version available" as a warning message since there is risk with not keeping integrations up-to-date

Example: