Fix TensorzeroHttpClient behavior for streaming requests

[Aaron1011]

We were double-decrementing the counter when constructing a TensorZeroEventSource, which could lead to the counter underflowing to the maximum value.

We now avoid decrementing the counter when we drop the original 'LimitedClientTicket', and test a mixture of streaming and non-streaming requests

---

Important

Fix double-decrement issue in TensorzeroHttpClient by adjusting LimitedClientTicket logic and add tests for streaming and non-streaming requests.

• Behavior:
  • Fix double-decrement issue in LimitedClientTicket by introducing should_decrement flag to control counter decrement.
  • Adjust into_owned() in LimitedClientTicket to set should_decrement to false when ownership is transferred.
• Tests:
  • Add tests in tests module to verify correct behavior for streaming and non-streaming requests.
  • Ensure tests cover scenarios with mixed request types and validate client initialization and request handling.
• Misc:
  • Update TensorzeroRequestBuilder to use into_owned() for eventsource() method.

^{This description was created by for 734662f. You can customize this summary. It will automatically update as commits are pushed.}

[Copilot]

Pull Request Overview

This PR fixes a double-decrement bug in the HTTP client's concurrency counter when handling streaming requests. The issue occurred when creating a TensorZeroEventSource from a LimitedClientTicket, which would cause the counter to be decremented twice and potentially underflow.

• Adds a should_decrement flag to LimitedClientTicket to control when the counter is decremented
• Introduces into_owned() method to transfer ownership without double-decrementing
• Adds comprehensive tests for both streaming and non-streaming requests to verify correct counter behavior

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}