Support extra query parameters

[bgavrilMS]

Consistency item with other MSALs - support extra query parameters. This is a map of key value strings which are applied to every HTTP call that MSAL makes, .e.g. {"key1":"val1", "key2","val2"}

It is applied to every HTTP call (including discovery and /token calls) that MSAL makes, irrespective of it being GET or POST, by adding these parameters to the URL. The /authorize URI that MSAL computes must also have these params. Conficts are resolved by favoring extra query params.

When using a broker, the extra query parameters are passed on to the broker's property bag. See https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/blob/main/src/client/Microsoft.Identity.Client/Platforms/Features/RuntimeBroker/WamAdapters.cs#L188

Scenarios:

• allows targeting ESTS test slices
• extensibility of broker scenarios

[rayluo]

Blindly sending arbitrary query parameters into all discovery and token calls would risk a potential future conflict of same param "foo" being used by different HTTP requests but have different meaning. As an example, one http request may expect an api-version=1.0 and another expects an api-version=2.0, this can't be solved by one common query parameter.

Currently, MSAL Python covers all the known scenarios with dedicate support.

• The MSA Passthough scenario is supported by a dedicated parameter, demonstrated by this sample.
• The test slices is supported by the authority url accepting arbitrary query string, which in turn affects the auth endpoint and token endpoint accordingly (via OIDC discovery).