Ensure we keep the same cached list and previous entries when SSP pages update

[richard-cox]

Summary

Fixes #15847

Occurred changes and/or fixed issues

• when a SSP enable page receives an update the entries in the store (list and map) get updated
• the map is just a key:value collection and was updated in place
  • new entries added, existing ones updated, old ones removed
• the list, which is an ordered array representing the page, was emptied and repopulated with the new page
  • this meant anything that referenced the old entries were disconnected from their new matching entries in the list
  • this broke places like sortable table selection that relied on object reference checks

Areas or cases that should be tested

• Deployments List - Selected Row Changes
  • Tab A - Deployments list - select a deployment
  • Tab B - scale up/down the deployment
  • Tab A - Row should remain selected, the deployment column's ready count should update
• Deployments List - Selected Row is removed
  • Tab A - Deployments list - select two deployment
  • Tab B - delete one of the deployments
  • Tab A - deleted deployment's row should be removed, the selected count should drop by one
• Deployments List - Row is added
  • Tab A - Select a deployment with name starting with something other than A. There are other deployments below that row
  • Tab B - create a deployment with name starting with A
  • Tab A - The originally selected row remains selected (but not highlighted)

Areas which could experience regressions

• This is an impactful change given it affects all paginated calls (tables, drop downs with pagination, anything else that uses the advanced filtering like label selector requests, etc)
• Table
  • Covered in core test cases
• Drop Down
  • Installing Logging app
  • Create some opaque secrets in a namespace (values do not matter)
  • Logging --> Output --> Create
  • Select namespace with secrets in
  • Output tab Access dropdowns should show secrets
• Label Selector example
  • similar set of tests as the deployments list, however the pods list in the deployment detail page

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]

/backport v2.13.2 release-2.13

[richard-cox]

/backport v2.12.6 release-2.12