[Cosmos] "Enable Content Response on Write" option and integration tests for items and query

[analogrelay]

This PR changes the default behavior for write operations to align with other Cosmos SDKs. By default, we instruct the server not to send the updated content of an item when writing it (Upsert, Replace, Patch, etc.). If a user wants the content returned for these operations, they must set the enable_content_response_on_write option. As part of this, I also changed the return types a bit:

• Read operations return Response instead of Response<T>. In order for Response<T> to "work", the T type has to implement the typespec_client_core::Model trait, a trait with is Azure/TypeSpec-specific. I didn't want to force users to do that. Fortunately, with Proposal: Rework body deserialization on Response<T> #1954 merged, we have another option. We can return Response and users can call Response::into_json_body to parse the JSON body to their own custom type which need only implement serde::Deserialize.
• Write operations also return Response since we expect them to have no body by default. If a user sets enable_content_response_on_write, they can parse the body with the same Response::into_json_body method.
• Database/Container-level operations still return full objects, even the query_... methods which could return projections. This aligns the Go SDK, but users still have the ability to parse any response into their own type using Response::into_json_body (even if the type is Response<DatabaseProperties>).

In addition, I changed our doc examples to use ? syntax (by having them be in async fn doc() -> Result<(), Box<dyn std::error::Error>> wrapper functions). It looks a lot cleaner that way, IMO, by removing all the noisy .unwrap() calls and matching more closely to what we expect users to do in their own applications.

Finally, I did need one change in the azure_core_test crate, because our live tests were broken by #1956 . I changed azure_core_test::recorded::start to return Result<Option<Session>> (instead of just Result<Session>). If the test is running in live mode, it'll return Ok(None), to indicate that no test proxy session was established. I think this is the right way to handle this, but I'm open to feedback.

I'm not expecting action on this until the new year, because I know @heaths is out until the new year and the azure_core_test change will need his ✅ , but I wanted to open it up and get Cosmos folks looking at it.

[kirankumarkolli]

How are changelog maintained for Rust?
For other SDK's we have changelog.md part of the repo and part PR or later during release we keep refreshing them.

[analogrelay]

How are changelog maintained for Rust?

Since we haven't made a release yet, there isn't really a Changelog. I expect that will start up after the first preview release. I do like how the other SDKs manage it, we can do something similar here.