Remove shielding from cancellation process.

[lovelydinosaur]

For handling async-cancellations we're currently shielding close operations, in order to ensure we don't end up with a connection in an inconsistent state when cancellations are used.

A better approach is to ensure that the state changes for this case are handled synchronously (so that cancellations won't propagate into those). While the network close remains unshielded async (it's okay for cancellations to propagate into those).

Reasoning about the state when cancellations occur is a bit fiddly, tho I think we can apply this same style of approach all the way through to remove the need for async cancellation-shielding. (Closing state is applied first synchronously. Network close operations are then attempted, and may propagate cancellation.)

Refs #922

[rattrayalex]

@tomchristie do you intend to take this over the line, or would it be helpful for someone else to try to take it over?

(for context, users of openai-python are reporting unusably slow performance, which seems related to https://github.com/encode/httpx/issues/3215)

[rattrayalex]

Any update here? Would contributions be welcome?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[T-256]

Bump