Remove API request consolidation across tabs.

[rtibbles]

Summary

Description of the change(s) you made

• In an attempt to limit duplicate requests to the server, there was a slightly overcomplicated system using broadcast channel to limit API requests using the resource layer to only originate from one tab
• This relied on a vendored, edited copy of the broadcast-channel leaderElection functionality, in order to be able to defer all data loading until after a leader had been elected
• Unfortunately this vendored version caused an issue where every tab became a leader, so nothing was solved
• This issue was fixed in Prevent duplicate sync polling #3251 by reverting to an upstream version of broadcast-channel's leaderElection
• However, because we are no longer waiting for the leaderElection to be decided, requests can be initiated before a leader exists, and so are not responded to and requested from the server
• This PR resolves this issue by removing this functionality completely and just initiating API requests from each tab individually
• In the future, similar functionality can be achieved in a more robust way by using Service Worker request interception.

Manual verification steps performed

1. Clear indexedDB
2. Load any page in Studio
3. Observe that data fetches complete

Reviewer guidance

How can a reviewer test these changes?

Are there any extant references to requestCollection or requestModel that I missed?
Do pages load as expected.

Are there any risky areas that deserve extra testing?

I think if anything, this reduces complexity and risk for the most part.

---

Contributor's Checklist

PR process:

• If this is an important user-facing change, PR or related issue the CHANGELOG label been added to this PR. Note: items with this label will be added to the CHANGELOG at a later time
• If this includes an internal dependency change, a link to the diff is provided
• The docs label has been added if this introduces a change that needs to be updated in the user docs?
• If any Python requirements have changed, the updated requirements.txt files also included in this PR
• Opportunities for using Google Analytics here are noted
• Migrations are safe for a large db

Studio-specifc:

• All user-facing strings are translated properly
• The notranslate class been added to elements that shouldn't be translated by Google Chrome's automatic translation feature (e.g. icons, user-generated text)
• All UI components are LTR and RTL compliant
• Views are organized into pages, components, and layouts directories as described in the docs
• Users' storage used is recalculated properly on any changes to main tree files
• If there new ways this uses user data that needs to be factored into our Privacy Policy, it has been noted.

Testing:

• Code is clean and well-commented
• Contributor has fully tested the PR manually
• If there are any front-end changes, before/after screenshots are included
• Critical user journeys are covered by Gherkin stories
• Any new interactions have been added to the QA Sheet
• Critical and brittle code paths are covered by unit tests

---

Reviewer's Checklist

This section is for reviewers to fill out.

• Automated test coverage is satisfactory
• PR is fully functional
• PR has been tested for accessibility regressions
• External dependency files were updated if necessary (yarn and pip)
• Documentation is updated
• Contributor is in AUTHORS.md

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
6 Code Smells

No Coverage information
No Duplication information

[marcellamaki]

Manual QA indicates this has resolved the loading issue! Code read-through also looks good and tests passing locally ✅