Cleanly handle error states for backend connection issues

[ohltyler]

Description

Improves the home page UI to cleanly handle scenarios where there are failures to the cluster (most commonly the backend plugin APIs), whether it is a local cluster or external data source (if MDS enabled). Before, there would be ad-hoc toast messages indicating the failures, but no limitation to navigating around the plugin, which could lead to weird side effects (buttons not doing anything, creation failing, etc.) when there was issues executing the plugin APIs. Now, we have blanket messaging on the page to prevent users from triggering these states altogether, and more obvious direction for the users to first fix their cluster before coming back to the UI.

The 2 caught scenarios are:
Scenario 1. Connection issues + MDS disabled: provide wording indicating failures accessing the cluster, and action wording to make sure the cluster has all necessary plugins installed.

Scenario 2. Connection issues + MDS enabled: provide wording indicating failures accessing the cluster, and action wording to make sure the cluster is available and has all necessary features available. Note: there may not be sufficient metadata in the configured data sources to know exactly why some API calls may be failing, so we keep the wording generic. We guide the users by directing them to the data source configuration for further debugging.

All scenarios tested:

• Non-MDS with plugins and created system indices
• Non-MDS with plugins and no system indices
• Non-MDS with missing plugins
• MDS + local cluster with plugins and created system indices
• MDS + local cluster with plugins and no system indices
• MDS + local cluster with missing plugins
• MDS + remote cluster with plugins and created system indices
• MDS + remote cluster with plugins and no system indices
• MDS + remote cluster with missing plugins

Also adds an edge-case NPE check on models in QuickConfigureModal to ensure it is not empty / undefined, which can happen in the case of connection issues to the ML plugin APIs from the backend. In general, this case should not be triggered, unless an intermittent failure. The other changes in this PR already block this from happening, if there is constant/persistent failures to the ML APIs from the connected backend.

Screenshots:

Scenario 1

Scenario 2

MDS (local cluster enabled, same behavior as before):

MDS (remote cluster, same behavior as before):

Demo video, toggling between local cluster / remote cluster w/ ML features / remote cluster w/ no ML features:

demo-mds.webm

Check List

• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[ohltyler]

There is no changes on lines 333-387; auto-formatting updated this part.

[ohltyler]

Verified integ tests pass locally. Failing on CI due to 3.1/3.2 version mismatch, will re-run after merging that PR.

  (Run Finished)


       Spec                                              Tests  Passing  Failing  Pending  Skipped  
  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ ✔  plugins/dashboards-flow-framework/c      02:43        6        6        -        -        - │
  │    reate_workflow_spec.js                                                                      │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘
    ✔  All specs passed!                        02:43        6        6        -        -        -