SDK-2771: [MB] Introduce support for auth tokens

[bucky-boy]

This one ends up being a large PR touching pretty much every part of the SDK, sorry.

The goal is to introduce support for auth tokens in the Yoti Docs client - we've already release them to prod. A subsequent PR will cover how auth tokens get created, this one is only addressing how they are used in http requests.

The Plan
The plan is that...

1. the SDK's should support both auth tokens and signed requests for the time being

• not all of Yoti's services support auth tokens yet
• this isn't a change we can just force on people at the drop of a hat, or simply because they want a new SDK version
• remember there are other features added to the SDKs that require bumping the sdk version too

2. the integrator / relying business is responsible for managing the auth tokens

• there are two ways of creating them - either use an endpoint for a 90 min token, or use Hub for a infinite token
• therefore there needs to be way for the integrator to provide a token to the SDK clients
• we will offer support for creating tokens on the api (upcoming PR) but we have no business offering scheduled services
  for token generation & management on other peoples servers

So we're looking for a simple, maintainable solution here. It is likely we'll retire support for signed requests at some future point and then require all integrators to move to auth tokens but we have no timescale for that.

The Pain
The problem we ran into is there never truly was one way of issuing a signed request. The nonce & timestamp were widely recognised as being part of a signed request but in truth nearly every signed request also needs an sdkId somehow. Some endpoints have that in the request path, some in a Header, some as an sdkId query param and some as an appId query param. It seems likely that most of these endpoints will not need the sdkId any more when they come to handle auth token requests.

All of the existing clients (& services) in the SDK use the SignedRequestBuilder. We did look at simply providing an alternative xxxRequestBuilder but that required a huge amount of duplication - even all the paths have to be redefined or messed about with the sdkId is so deeply ingrained.

So we've invented the AuthStrategy interface, and made the SignedRequestBuilder into a YotiHttpRequestBuilder. The implementations of AuthStrategy - named for each service they're calling - will apply the correct headers & query params for either a signed request or an auth token request.

We see this working fine for the Docs endpoints but the connect bits ought to be looked at @irotech (this will all need a thorough regression test anyway before it goes out).

[irotech]

I started looking into this PR and I'll need also to test it asap

[bucky-boy]

I started looking into this PR and I'll need also to test it asap

Since we're only merging into dev, we were thinking we'd merge it so that the SNAPSHOT can be built & tested.

[sonarqubecloud]

Quality Gate passed

Issues
5 New issues
0 Accepted issues

Measures
0 Security Hotspots
68.0% Coverage on New Code
2.3% Duplication on New Code

See analysis details on SonarQube Cloud

[irotech]

Tested locally the share-v1, share-v2 and DID match flows from the example project with the previous setup and all seem to work as expected

[pn-santos]

I'm not that familiar with this codebase but fwiw I skimmed through it and nothing jumped out worth pointing out related to the change.

Since @irotech has had more hours looking at this codebase I'll defer to him. As far as I'm concerned feel free to merge.

[pn-santos]

All these methods kinda no longer are exclusively "signed" requests, should they be renamed createRequest?

[bucky-boy]

Good spot, thank you. I'll take a look and raise a separate change.

[irotech]

I was about to add few minor comments around reducing the verbosity of member|var|arg names often as same as the type or use sdkId instead of appId everywhere but neither we have a proper coding style nor this suggestions are for new code. As mentioned in previous comment I tested locally the shares and did examples pointing stg env.

[bucky-boy]

I don't mind opening a new PR with other changes / improvements in it @irotech