UDP receiver async - fix panic during shutdown (async mode only)

[hovavza]

Description:
Link to tracking Issue: Fixes #29120
Fixing a bug - panic happens during stop method in async mode only (didn't affect the default non-async mode).
When stop is called, it closes the messageQueue channel, signaling to processMessagesAsync to stop running. However, readMessagesAsync sometimes tries to write into the closed channel (depends whether the method is currently reading from the closed connection or currently trying to write to the channel), and as a result, panic error happens.

Separated between wg (waitGroup that serves non-async code and processMessagesAsync) & the new wg_reader (waitGroup serving readMessagesAsync only). This allows us to first stop readMessagesAsync, wait for it to finish, before closing the channel.
Instead, stop (in async mode) should do the following:

1. Close the connection - signaling readMessagesAsync to stop - the messageQueue channel will remain open until that method is done so there's no risk of panic (due to writing to a closed channel).
2. Wait for readMessagesAsync to finish (wait for new wg_reader).
3. Close messageQueue channel (signaling processMessagesAsync to stop)
4. Wait for processMessagesAsync to finish (wait sg).

Link to tracking Issue: 29120

Testing: Unitests ran. Ran concrete strato, stopped & restarted multiple times, didn't see any panic (and stop completed successfully as expected)

Documentation: None.

[atoulme]

The changes make sense to me, is there a way to write a test to reproduce the issue?

[hovavza]

The changes make sense to me, is there a way to write a test to reproduce the issue?
@atoulme , I'm not sure how. There is the TestInput test method that would fail if the Stop method failed (including panic), including in the async mode. However, it's a matter of luck and volume. The readMessagesAsync method needs to be after the read-from-port line and before the channel addition while the Stop is called. In low traffic scenarios like the tests, this wouldn't happen.

[crobert-1]

Hello @hovavza, can you update the PR description with the following line?

Link to tracking Issue: Fixes #29120

This will allow GitHub to properly link this to the issue it's fixing.

[hovavza]

Hello @hovavza, can you update the PR description with the following line?

Link to tracking Issue: Fixes #29120

This will allow GitHub to properly link this to the issue it's fixing.

@crobert-1 done

[hovavza]

@djaglowski @crobert-1 @atoulme , can we complete this PR?