[MAINT] Check if listener events are properly set on a group also when accepting sockets over different listeners

[ethouris]

There's a part of the group code where it is intended to subscribe for epoll events for listening.

Likely it was intended to make it possible to interrupt waiting for a lingering connection, while a new connection was reported at the same time and this should make the group reader interrupt waiting, add this socket to the list of candidates, and continue waiting, possibly this time finding the new connection delivering data.

The code contains a registered listener socket that is only checked this time, so it's not set anew when this is the first socket accepted off given listener; for next it will see the listener set and skip it. But then, it will skip this step also in case when a new socket was accepted off a different listener, which means that waiting won't be interrupted if a new socket is accepted off a different listener than the one of the very first socket accepted for this group.

This could be a problem for backup groups - in case of broadcast groups they are intended to deliver data all the time over every link, so interrupting the wait call will happen by different reasons, but still early enough. Backup groups may experience hanging in reading function due to that the waiting function is unaware of that another connection in the same group is ready to deliver data, while the other connection went silent.

[ethouris]

Having a registered listener doesn't solve this problem, especially in the following situation:

1. You have a listener. This listener provides an accepted socket that will be added to a group.
2. Your group has one member and is now connected.
3. You close the listener, while the group is still in use.
4. After some time the group transmission is frozen.
5. You create a new listener. Then the listener provides a new socket that will be a member of the same group.
6. While the previous existing member link doesn't transmit anything, the waiting function will not be interrupted due to a new accepted socket, which potentially might provide data.
7. The newly accepted socket will be added to the group, but it won't be polled for data!

The problem: how to make the waiting function interrupt while the newly connected socket comes from a listener that was unknown before the receiver function was called?

The problem is that the listener cannot be the update point for this event because:

• Any listener can provide a new member connection to this group
• A listener that provided an existing connection need not exist at the time when the new member is connected.

A proposed solution should be provided in #1891