Races and memory leak for ReceptionStatusAwaiter

[philipptrenz]

Hi all,

we hit a couple of issues with the current ReceptionStatusAwaiter implementation:

• Race on cleanup: both the waiter and receiver do del self.awaiting[...], which can lead to KeyError if they delete the same entry around the same time. Using pop(..., None) avoids this.
• Unbounded growth: self.received keeps every status forever, so it will grow without limit in long-running processes.

A clean fix would be to treat reception statuses as single-consumer: once awaited, remove them via pop(). That also makes the semantics simple: only one coroutine may await a given message_id.

Would it be acceptable to update the code with that assumption (single awaiter per message id), plus safe cleanup using pop()? If so, I'd have a PR ready.

If multiple awaiters are actually expected, we might have to look into a different approach (e.g. Futures/shared results).

FYI @realdognose @ReinvdZee