fix(axe-core-4.2.0): replace usages of axe._tree with axe.setup

[dbjorge]

Details

axe-core 4.2.0 deprecated direct access to the internal axe._tree in favor of new axe.setup and axe.teardown APIs in dequelabs/axe-core#2738. This PR replaces our usage of the deprecated thing.

The changes include:

• Rewriting getUniqueSelector (and giving it unit tests, which it was missing)
• Moving it from ScannerUtils to AxeUtils as part of its rewrite (it has no dependencies on the Scanner, and AxeUtils is where all the other axe-internal usages live)
  • As a result of this, updated window-initializer to drop its ScannerUtils dep
• Creating a withAxeSetup wrapper for both getUniqueSelector and unit tests to use
• Updating a bunch of unit tests (mostly of our custom checks/rules) to use withAxeSetup instead of manual _tree manipulation
• Adding an end to end test page for custom widgets (tests for the custom widgets checks were impacted, so I wanted to make sure I exercised the checks during my manual validation of the PR)

Motivation

There are a few reasons we want to do this.

First, just as technical debt avoidance (avoiding dependency on a deprecated thing).

Second, axe.teardown() does more cleanup than we were previously doing in getUniqueSelector; this avoids the possibility of getUniqueSelector leaking some invalid bit of cache data into a subsequent scan.

Third, because setup contains an assertion that it hasn't already been called (eg, by axe itself while a scan is in progress), this improves our the behavior when getUniqueSelector is called while an axe scan is in progress. Practically speaking, this could happen if a user attempted to use the tab stops visualizer or the scoping feature's element selector while a scan is in progress. Previously, this would blindly overwrite axe's internal state while the scan was in progress, and was liable to cause silently incorrect scan results. With this change, the visualizer/selector operation will instead throw an error, and the scan will continue uninterrupted.

I don't think it's super likely for users to hit this conflict in practice, but if a user did, I think a visualizer/selector failing and needing to be retried is vastly better than scan results being unpredictably inaccurate.

Context

Pull request checklist

• [n/a] Addresses an existing issue: #0000
• Ran yarn fastpass
• Added/updated relevant unit test(s) (and ran yarn test)
• Verified code coverage for the changes made. Check coverage report at: <rootDir>/test-results/unit/coverage
• PR title AND final merge commit title both start with a semantic tag (fix:, chore:, feat(feature-name):, refactor:). See CONTRIBUTING.md.
• [n/a] (UI changes only) Added screenshots/GIFs to description above
• [n/a] (UI changes only) Verified usability with NVDA/JAWS

[peterdur]

Do we need the await on this line? getUniqueSelector is not declared async above.

[dbjorge]

Nope! This was leftover from when I was experimenting with having it wait for any ongoing scans to complete, removed

[jalkire]

Validated tab stops related behavior locally 👍