Ensure user authentication sessions are independent

[esune]

Resolves #362

Previously, the user authentication sessions was always leaning on the same "fake user" in the Userinfo database to store data temporarily. This lead to issues when multiple concurrent authentication requests were attempted: data from a user authentication session would pollute other user authentication sessions, leaking information.

The fix involved:

• defining a custom VCUserinfo class that overrides the methods in Userinfo responsible for returning data
• ensuring each authentication request is associated with a new, random user identifier to prevent polluting existing data
• in order to support both scenarios were the proof defines/doesn't define a subject_identifier, the generation of the claims object was updated to only include the sub claim if the proof-request defines one, and ensuring the token endpoint accounts for the custom sub, if present.

[jamshale]

I'd need to study this more to fully understand why the problem occurred.

It looks like you know what you're doing though 👍

[esune]

I'd need to study this more to fully understand why the problem occurred.

It looks like you know what you're doing though 👍

Added two notes to try and clarify, but I am confident this is the right approach. It definitely was painful to figure out what the underlying library was doing 😅