[Cosmos] Session container fixes

[simorenoh]

This PR aims at closing several gaps in the session token handling logic of the Python SDK's session container. This PR also addresses and closes #39464 and #36287.

Current state

The Python SDK currently does several things that should be improved upon for session consistency behaviors:

• We currently send out a session token for every single request so long as the default account consistency is Session, which is undesired behavior for write operations in single-write region scenarios.
• The session token that we send out with our requests is a compound session token including every single partition in the container, which is unfeasible for large accounts since these can become large enough to cause request size issues.
• The SDK had no pk cache refreshing logic for partition split scenarios since we don't receive 410/1002 status codes to react to for normal requests sending out a partition key value and not a partition key range id.
• The SDK was not updating session tokens after read requests, allowing stale reads for workloads if other clients are interacting with the same container resource.

Changes introduced

In order to address the above issues, the following changes have been made:

• We will now only send out session tokens for the relevant requests under session consistency - read operations, batch operations, or requests sent by multi-write configured accounts.
• The compound session token that gets sent out once a partition splits will now only have its relevant parent(s) included as opposed to the entire contents of the container partitions.
• Now, once we receive a partition key range id in the response headers that is unaccounted for in the partition key range cache, we will force a refresh to the cache in order to obtain all the new ids to be used in session token computing for subsequent requests.
• We now update session tokens on read requests as well, ensuring all requests are fetching the newest available session token.

Caveats

We currently only initiate the session container within a client if the user properly initializes their client. While this is not a problem for the sync client, it means that users that are not directly initializing their asynchronous clients as outlined in our README will not be able to leverage the session container, and will have to implement their own session token handling logic to achieve session consistency.

Currently working on developing tests that we can use for this.

[azure-sdk]

API change check

APIView has identified API level changes in this PR and created following API reviews.

azure-cosmos