instruducing inner data for Client to avoid extra Allocations

[MrAliSalehi]

Pull Request

Related issue

What does this PR do?

Hello there, Thank your for your Library <3

this PR adds an extra object into the Client type, it wraps the inner content inside an Arc in order to avoid allocations when using Clone . this is a simple and known pattern in Rust community.
tho this can be done from outer scope where users could just simply wrap the Client itself inside an Arc, its a nice feature to have inside in case users forget about this case and accidentally Clone the Client without an Arc.

this PR also includes an impl (perhaps it should be placed somewhere else, im not sure about the author's preference on this) to deref the Client into ClientInner. this allows user to use the self. (the client ) normally just like before without needing to call self.inner.

also i added 2 .clone() to the test to make them work normally. which i think is not really important.

this PR should not introduce any breaking changes for users (neither for developers & contributors).

PR checklist

Please check if your PR fulfills the following requirements:

• Does this PR fix an existing issue, or have you listed the changes applied in the PR description (and why they are needed)?
• Have you read the contributing guidelines?
• Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

[curquiza]

Hello @MrAliSalehi

Thank you for your PR
Can you fix the rust format Ci please?

[Mubelotix]

Hi @MrAliSalehi, thanks for the PR. While this change does provide a slight performance improvement in cases where the client is cloned frequently, it also introduces a small performance overhead in scenarios where only a single client is used.

I believe it's already possible for library users to wrap the Client in an Arc, correct? If so, could you try that approach instead? Alternatively, if that's not feasible, using Box::leak to create a static client is another option. As long as your application doesn’t require handling multiple client configurations during its lifetime, that should work well.

I'll go ahead and close this for now, but feel free to reach out or ask us to reopen it if you find that these suggestions aren't viable.