Add Cosmos db manual session token management

[JoasE]

Allows the user to retrieve session tokens from reads and writes done by a dbcontext and set session tokens to use for reads.
Adds a GetSessionTokens() extension method to DatabaseFacade which returns session tokens per container.
Adds a AppendSessionTokens() extension method to DatabaseFacade which allows appending session tokens per container.
Adds GetSessionToken() and AppendSessionToken() for the default container.
Adds option ManualSessionTokenManagementEnabled to CosmosDbContextOptionsBuilder

Implements: #36504

• I've read the guidelines for contributing and seen the walkthrough
• I've posted a comment on an issue with a detailed description of how I am planning to contribute and got approval from a member of the team
• The code builds and tests pass locally (also verified by our automated build checks)
• Commit messages follow this format:

        Summary of the changes
        - Detail 1
        - Detail 2

        Fixes #bugnumber

• Tests for the changes have been added (for bug fixes / features)
• Code follows the same patterns and style as existing code in this repo

[JoasE]

A few questions from me still

[JoasE]

Wondering if this needs to be a wrapper and have an SessionTokenStorageInternal.
Also wondering about naming: CosmosSessionTokenStorage?

[AndriySvyryd]

I now think that this API might be somewhat clunky to use. Perhaps this should just implement IReadOnlyDictionary<string, string> and that's what GetSessionTokens returns. AddSessionTokens(IReadOnlyDictionary<string, string>) will merge in the passed values and that's when you'll check container names (when the tokens are set internally we know that the containers are correct). I think this will make the common case of just moving all tokens from one instance to another easier and since it's not a special type it would also be simpler to (de)serialize in the app. This also avoids the potential ambiguity of the API using the default container name.

[JoasE]

If this implements IReadOnlyDictionary then the values in the reference the user receives will change after using a query or savechanges. Preventing them from having to call GetSessionTokens multiple times, but it might be confusing that it doesn't return a snapshot. Thoughts on this?

[AndriySvyryd]

You are right, returning a snapshot would be less confusing. And it's also unlikely that developers would need to call GetSessionTokens frequently on the same context instance.

[JoasE]

Moved to returning a snapshot

[JoasE]

I've kept the ambiguity, as I personally feel most users will use a single container per DbContext, and working with the SetSessionTokens api becomes a bit of a hassle having to always specify the default container name. Let me know if you still think this is a bad idea

[JoasE]

In SessionTokenStorage I want to check whether the container exists if a user is appending or adding a session token. It felt expensive to do GetContainerNames every DbContext instantiation, while I felt it could be a property of the model. However, I am not sure if annotations are the right way to add this data to the model for the cosmos provider. I am also not sure what would be the best place to calculate this metadata and set the annotation. Doing this this way fails CompiledModelCosmosTests and I am not sure if there is actually something wrong or the test should change and if so how.

[JoasE]

@AndriySvyryd or @roji Could you provide some guidance on this?

[AndriySvyryd]

With the above proposed design you shouldn't need this

[JoasE]

Ahh I see what you mean now. Updated this to do the check in the Extension method and removed the annotations

[AndriySvyryd]

Suggested change

	<value>Enable manual session token management using CosmosDbContextOptionsBuilder.ManualSessionTokenManagementEnabled to use this method.</value>
	<value>Enable manual session token management using 'options.ManualSessionTokenManagementEnabled' to use this method.</value>