Expose transport retries as `connect_retries` in client options

[zanieb]

trafficstars

Opening this draft of previously discussed addition of an option to set connect retries on the client.

Next steps:

• [ ] Pass type checking in CI
• [ ] Agree on a testing strategy
• [ ] Pass tests in CI

[zanieb]

See https://github.com/encode/httpcore/pull/643 to resolve type errors (outside of tests) by adding retries to SOCKS proxy classes.

[lovelydinosaur]

Ah neat.

So...

I don't think we need test cases where what we're doing is passing through an argument, and then inspecting the private implementation details to see that it's been set. It should be enough that we have type-checking throughout. The retries API is provided by httpcore, and is tested by httpcore. Separation of concerns etc.etc.

I wonder if we should be avoiding too much top-level configuration API on the client. Perhaps retries or connection_retries should be in the Limits(...) config?

[zanieb]

I don't think we need test cases where what we're doing is passing through an argument, and then inspecting the private implementation details to see that it's been set.

I agree this is really awkward — however, since the behavior differs if you provide your own transport I feel we need a little bit of test coverage? I'm definitely okay with whatever you're comfortable with. Perhaps we should throw an error if you provide a value for this and a transport.

I wonder if we should be avoiding too much top-level configuration API on the client. Perhaps retries or connection_retries should be in the Limits(...) config?

I agree it'd be nice to keep things out of the top-level. Limits feels like a weird place though — everything there is non-zero by default. I don't feel like this setting is adjusting a reasonable upper bound (as limits imply), it's enabling behavior.

[zanieb]

My need for this is not pressing as I've implemented wrapper around the client but I'd love to keep discussing the best way to handle this when you have time!