Fix delay when navigating to a cluster

[richard-cox]

Summary

Fixes #17634

Occurred changes and/or fixed issues

• issue 1
  • loadCluster --> await dispatch('cluster/unsubscribe'); --> cleanupTasks.push(waitFor(() => !this.$workers[getters.storeName], 'Worker is destroyed'));
  • the waitFor was not immediately resolved, so waited the default 500ms before checking again
  • for some reason we're now not in the immediate world so wait the 500ms
  • resolution is to reduce the delay in waitFor to 50ms
  • i haven't managed to work out why this is now an issue, so this is almost a work around (but a logical one)
• issue 2
  • race condition for loadCluster and feature flag
  • we check if vai enabled (via FF), and if not wait for all mgmt clusters. with vai disabled this is fetched later on
  • however if FF aren't fetched by the time we decided to wait for mgmt clusters.. we wait... and if FF are later fetched and vai is enabled we won't fetch all clusters.... so the UI blocks on blue spinner until the wait fails

Technical notes summary

• Superseded
  • Fix delay when navigating to a cluster #17641
  • Fix delay when navigating to a cluster - CI tests #17703

Areas or cases that should be tested

• home page --> cluster list --> cluster (quicker than before, at least 450ms)
• nav to any cluster --> Workloads --> Deployment page --> refresh ~5 times (should always load quicker than 10 seconds...)

Areas which could experience regressions

• cluster --> home page --> cluster list (this is as quick as before)

Checklist

• The PR is linked to an issue and the linked issue has a Milestone, or no issue is needed
• The PR has a Milestone
• The PR template has been filled out
• The PR has been self reviewed
• The PR has a reviewer assigned
• The PR has automated tests or clear instructions for manual tests and the linked issue has appropriate QA labels, or tests are not needed
• The PR has reviewed with UX and tested in light and dark mode, or there are no UX changes
• The PR has been reviewed in terms of Accessibility
• The PR has considered, and if applicable tested with, the three Global Roles Admin, Standard User and User Base

[richard-cox]

I re-ran the whole suite of tests 10 times. No single run passed all tests. Many failed on different tests each time

I've dived into them all and i don't think any are now related to this PR. The number of same tests sequentially failing is low and i expect are failing in other PRs but pass on the automatic second run

Ones of note

• manager
  • edit-fake-cluster - failed 7/10. not related. fixed in another PR
• explorer2
  • cron jobs - failed 2/10. i don't think this is related. looks like a timing issue (failing to fetch / watch a resource when going from cronjob list to detail page
• explorer
  • cluster-dashboard - failed 4/10. i don't think this is related. looks like a permission error given the admin user session isn't correctly restored causing failures in an after block deleting resource
• various
  • rancher-setup - failed 3/10. i don't think this is related. looks like a failure when create the user (could be a timing one, we create and then fetch and it's somewhere around there). test though doesn't handle re-runs well

From run 10 (re-running failed suites)

• 11 - 1 failure - manager / repositories(new!)
• 12 - 1 failure - manager / edit-fake-cluster
• 13 - 1 failure - manager / edit-fake-cluster

[richard-cox]

these are changes already in via #17739

[richard-cox]

i've made the check

• safer given $workers and getter might get nuked
• limited to 30 seconds, it really shouldn't take that long
• check every 10ms
• log activity (which will help in future)