Lab Migration

[Avery-Dunn]

MSAL Java version of the work done in AzureAD/microsoft-authentication-library-for-dotnet#5558

We are migrating from getting test config from the ID Labs API to a more Key Vault-based approach. This work was recently completed in MSAL .NET, and this PR makes similar changes in Java.

A lot of files were changed in this PR, reviews can focus on a single folder at a time since all the files in each received similar changes:

• Files in com.microsoft.aad.msal4j/
  • Any class ending in "IT" is an integration test, and other than the removed/added tests described below they mainly just received changes to use the new helper classes
  • Any class not ending in "IT" is a helper, and these either received a few changes or were completely removed
• Files in com.microsoft.aad.msal4j/labapi/
  • All of the new helper classes for the new system, and as long as the tests are succeeding they shouldn't need a deep review
  • They have similar names/styles and for a few Github is showing them as simply moved from another directory, but they can all be considered brand new
• Files in infrastructure/
  • Our Selenium infrastructure for running browser-based tests, completely refactored to better follow Selenium conventions and standards
  • As with the other helper classes, as long as the tests are succeeding they shouldn't need a deep review
• Files in labapi/
  • The old system, completely removed and replaced with the files in com.microsoft.aad.msal4j/labapi/
• Misc. other files:
  • pom.xml: updated with a few new test-only dependencies
  • AuthorizationResponseHandler: unrelated to the lab migration, this just fixes a long-neglected issue (Missing error and error_description when acquiring the token interactively #513) that I was reminded of when testing the new system

In addition to the lab migration, some test scenarios were streamlined to avoid over-testing or testing deprecated services:

• ADFS: ADFS 2022 is now covered by tests, and older deprecated ADFS versions were removed (2019, v4)
• National clouds: we decided this was over-tested and mostly behaves the same from an MSAL perspective, so other than a few remaining Arlington tests most of them were removed

[bgavrilMS]

I don't understand why we need dedicated user for PCA. I agree we need dedicated app, but not user. @RyAuld ?

[RyAuld]

I agree that there shouldn't be a reason for user unless there is a CA or role grant policy based on user involved with the test itself. I don't think there is in this instance.

[Avery-Dunn]

The mergeLabResponses() method that all of these helper methods use takes in the names of three key vault "secrets": one for the user, one for the lab, and one for the app, which are pretty much just the same sort of JSON responses from the old /user, /app, and /lab API endpoints.

These helper methods all use the same "MSAL-User-Default-JSON" user but different apps, and they just merge that user info with different app info.

[Avery-Dunn]

In the latest commit I renamed some of these helper classes/methods and added more comments to hopefully clarify what it's doing: it's not just fetching user config, rather it's getting whatever combination of user/app/lab config is needed for the test scenario.