Fix safety issues with AsyncClient destruction in user callbacks

[willmmiles]

Ensure no use-after-frees occur if the AsyncClient object is destroyed while in a user callback. This guarantees correct behavior if user code calls close() in an event callback (such as onData, onPacket, onTimeout, etc.) and frees the AsyncClient in the onDisconnect() callback.

Note that this does not insulate the user callback code itself against internal use-after-free events, such as using a captured lambda value after destroying the AsyncClient and thus the std::function storing the capture. Any user code that could destruct its own AsyncClient must be cognizant of the risks. We may want to consider an explicit "deferred close" API to make it easier for clients to reason about their own code.

Includes a couple of other little tweaks:

• Removed duplicate #include (probably a merge issue somewhere earlier)
• Ensure that _rx_ack_len is initialized

[Copilot]

Pull request overview

Adds callback-lifetime tracking to prevent AsyncClient use-after-free during user callbacks.

Changes:

• Tracks client validity across nested callbacks.
• Safely stops receive processing after closure/destruction.
• Initializes _rx_ack_len and removes a duplicate include.

Reviewed changes

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

File	Description
src/AsyncTCP.h	Adds callback context state and moves ackLater() implementation.
src/AsyncTCP.cpp	Implements callback safety, receive cleanup, and initialization fixes.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[willmmiles]

Arg. Upon re-re-review, I think there might still be something off with the close()-from-onData() semantics. If close() is invoked from an onData() callback, with this patch as-is we'll never ack that final packet (instead we sent TCP RST). This is not new but probably not the ideal behaviour.

[willmmiles]

Arg. Upon re-re-review, I think there might still be something off with the close()-from-onData() semantics. If close() is invoked from an onData() callback, with this patch as-is we'll never ack that final packet (instead we sent TCP RST). This is not new but probably not the ideal behaviour.

Updated with a fix for this. To be clear, the issue of incorrectly sending RSTs if we close() from onData() was not new to this branch, it's also a probem in main -- but since I'm in there updating the close handling semantics, might as well get them all straightened out at once.