Add nats-client package

[caspervonb]

This adds a standalone nats.client package

Main differences in nats.client compared to nats.aio

• Asynchronous first
• Substantially faster than nats.aio
• Proper headers, with support for multi-values.
• JetStream unaware as a feature.

[Copilot]

Pull Request Overview

This PR adds a new NATS client package with significant performance improvements over the existing nats.aio client. The implementation provides core NATS messaging functionality including publish/subscribe, request/reply, queue groups, and message headers through an asyncio-based Python client.

• Introduces a complete NATS client implementation with high-level API
• Adds comprehensive test coverage for all client features and edge cases
• Includes performance benchmarking tools demonstrating 35x improvement for small messages

Reviewed Changes

Copilot reviewed 20 out of 20 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
nats-client/src/nats/client/init.py	Main client implementation with connection management, messaging, and reconnection logic
nats-client/src/nats/client/subscription.py	Subscription class supporting async iteration and context management
nats-client/src/nats/client/protocol/message.py	NATS protocol message parsing with support for MSG, HMSG, and control messages
nats-client/src/nats/client/protocol/command.py	Command encoding for NATS protocol operations (PUB, SUB, CONNECT, etc.)
nats-client/src/nats/client/message.py	Message data structures including Headers, Status, and Message classes
nats-client/tests/	Comprehensive test suite covering client functionality, subscriptions, and protocol handling
nats-client/tools/bench.py	Benchmarking tool for performance testing

---

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

[wallyqs]

Move this to be under nats.experimental.client to be able to use both while still evaluating the client.

[philpennock]

I don't see anything in the SSL context init to handle the server identity for TLS identity verification, when we learnt a reconnect address as an IP from the INFO line?

If we connect with a hostname originally, we validate that hostname in the cert, and if we reconnect to a learnt IP address, we validate that same original hostname as present in the new server cert. Did I just miss the handling of that?

[Copilot]

Pull Request Overview

Copilot reviewed 21 out of 22 changed files in this pull request and generated 4 comments.

Comments suppressed due to low confidence (1)

.github/workflows/test.yml:1

• Git merge conflict markers are present in the CI configuration file. These need to be resolved before merging.

name: test

---

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

[Copilot]

Pull Request Overview

Copilot reviewed 21 out of 22 changed files in this pull request and generated no new comments.

---

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

[wallyqs]

Change the import to nats.experimental.aio.client while iterating on the implementation, then can work using that namespace in the other branches with the JetStream changes.

[caspervonb]

Change the import to nats.experimental.aio.client while iterating on the implementation, then can work using that namespace in the other branches with the JetStream changes.

So nats-experimental-aio-client as a package name? doesn't exactly roll of the tongue so not sure about that.

Also would make all the currently pending PRs painful to merge and also the ones that aren't opened yet (e.g client auth, client tls, jetstream ordered consumer). Not sure what the benefit is of such a rename?