Enable plugins to augment visualizations with additional data and context

[ohltyler]

Description

Enable plugins to augment visualizations with additional data and context

TODO:

• Ensure legacy functional tests are all passing (in other words, no new failures than the ones currently seen on main)
• Clean up any weird changes caused by all of the merges from main
• Add documentation / README (to resolve [Feature Anywhere] [Meta] Add documentation for Feature Anywhere #3383)
• Finish integration tests - see here for open issue list

Issues Resolved

Closes #2880

Screenshot

See meta issue for associated screenshots

Testing the changes

1. Start a cluster with AD and/or alerting plugins installed
2. Ingest some sample data
3. Create a simple line visualization with a simple metric / set of metrics (e.g., Average of field-1) and a date histogram for the x-axis
4. Add to a dashboard and save
5. Under the options menu for the visualization, select "Anomaly Detection" or "Alerting" options to create or associate an existing detector/monitor to the visualization
6. View alerts on the chart after the detector/monitor produces anomalies/alerts, respectively
7. Click on the events on the chart or click on "View events" in the options menu for the visualization to view a breakdown of the events based on plugin type and plugin resource type (e.g., detector/monitor)
8. View associated detectors/monitors by navigating under the respective plugins options menus

Check List

• All tests pass
  • yarn test:jest
  • yarn test:jest_integration
  • yarn test:ftr
• New functionality includes testing.
• New functionality has been documented.
• Update CHANGELOG.md
• Commits are signed per the DCO using --signoff

[ashwin-pc]

The PR looks great! My only concern is about how we are implementing the cleanup logic. Spoke offline with @ohltyler and the plan is to add comments in the code that link back to the issue highlighting the change thats needed so that we address the scalability of the solution before using the pattern in other places.

[ashwin-pc]

@ohltyler How necessary is this feature? Just to be clear, i'm talking about auto clearing the associated objects from only the saved object management page and not in the other places. Since we already dont do something similar for other objects and given that this isnt the best way to it right now, i'm wondering if we can skip this part of the change all together and keep it as an open issue to resolve it correctly for saved objects as a whole?

Other plugins are going to do the same soon and will look at how you guys did it as a model (ML team is also looking at this). If this is not the way we want to do it long term, I would like to either get it right or defer this until we can. This pattern is also bad for UX because it does not make it clear for the user when related relationship's will be deleted. Currently the expectation is that deleting a saved object will not delete the associated saved objects.

[ashwin-pc]

Ship it!

[opensearch-trigger-bot]

The backport to 2.x failed:

The process '/usr/bin/git' failed with exit code 128

To backport manually, run these commands in your terminal:

# Navigate to the root of your repository
cd $(git rev-parse --show-toplevel)
# Fetch latest updates from GitHub
git fetch
# Create a new working tree
git worktree add ../.worktrees/OpenSearch-Dashboards/backport-2.x 2.x
# Navigate to the new working tree
pushd ../.worktrees/OpenSearch-Dashboards/backport-2.x
# Create a new branch
git switch --create backport/backport-4361-to-2.x
# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick -x --mainline 1 13581354673c24df9d5422a9a0a20878687cd93e
# Push it to GitHub
git push --set-upstream origin backport/backport-4361-to-2.x
# Go back to the original working tree
popd
# Delete the working tree
git worktree remove ../.worktrees/OpenSearch-Dashboards/backport-2.x

Then, create a pull request where the base branch is 2.x and the compare/head branch is backport/backport-4361-to-2.x.

[manasvinibs]

@ohltyler Can you manually backport this change to 2.x branch as auto-backport has failed?