Reduce complexity of request builders and clients

[rylev]

This change makes all the clients concrete types without trait equivalents which makes all the code much simpler. While the examples need to use a few more calls to clone, I believe that ultimately this code is dramatically simpler and nearly 5K LOC less to maintain.

[thomastaylor312]

I'll admit that I did not comb over every line, I did go over this with you in (virtual) person and this refactor looks like a good step forward

[MindFlavor]

Excellent work (and super quick as well!) ❤️ .
I like the fact you renamed the struct as the removed traits (ie PermissionClient is better than PermissionStruct).

The clone() before into_document_client() and similar is well worth the removal of a Cow.

As for the request builders, I think taking the reference of the client is still the right choice given the short lived lifespan of a request (even if forces a lifetime). Most of the time they will consumed in a single call.

[thomastaylor312]

@MindFlavor Speaking as someone who is trying to use it, I'd prefer not to have the lifetimes. I will want to keep a reference to a configured client pointing at a specific collection and don't want/need to explicitly specify lifetimes. This new way allows me to embed these clients with ease in a struct. Willing to try the other way, but I think being able to embed and reuse these is helpful as a simple clone is negligible in comparison to a network call

[MindFlavor]

[...] This new way allows me to embed these clients with ease in a struct.

Sorry I was not clear, I was just acknowledging that the current implementation (rylev's, the one of this PR) is the right balance between ease of use and flexibility even if there still is a reference (with a lifefime). ie from the examples:

    let create_document_response = client
        .create_document()                              // this takes a reference to client
        .with_partition_keys(&partition_keys)
        .with_is_upsert(true)
        .execute_with_document(&doc)
        .await?;                                        // the reference is dropped here

What I was saying is: while it would be possible to remove this reference too (along with its lifetime) I don't think it would be a problem because 99% of the time the reference will be dropped in the same line (as the code above). Generally speaking, there is no upside of carrying around an half-completed request (currying here is basically pointless).

Anyway we can always remove it later but, IMHO, having to clone the client at every single function call would be awkward.

[thomastaylor312]

Ah ok, I get what you are saying now