Expose RequestStrategy as a param to post_form function

[azhur]

Is your feature request related to a problem? Please describe.

RequestStrategy is currently stored in the client which kinda makes it global so if you need to have a dedicated strategy per request you need to modify it in the client scope before every request. In the multithreaded environment, this might be a problem unless you clone the client per request which is not efficient in my understanding.
Exposing RequestStrategy to post_form allows user to specify it per request. For example user wants to create invoice in Stripe and use RequestStrategy.Idempotent(key) where the key is some invoice_id stored in user's application.

Describe the solution you'd like

No response

Describe alternatives you've considered

No response

Additional context

No response

[arlyon]

Thanks for the suggestion, and sorry for the delay in replying, I have been waiting to reply until we had more progress on '1.0'. I am going convert this to a discussion for now. I agree that cloning the client for a strategy change is not ideal; the current plan is instead having the strategy be a wrapper on top of the client with an arc to the client so you can clone it at will. That will help detach the implementations and make strategies user-implementable also. To do this we need to rework the clients to get rid of the client features, replacing them with a regular old trait (and leveraging GATs).

All I can say is 'this is coming!'