backport: merge bitcoin#24356 (replace CConnman::SocketEvents() with mockable Sock::WaitMany()), implement Sock::WaitMany{Epoll,KQueue}()

[kwvg]

Additional information

• Dependent on backport: merge bitcoin#21167, #22782, #21943, #22829, #24079, #24108, #24157, #25109 (network backports: part 5) #6004

• Dependent on refactor: move {epoll, kqueue} (de)init logic and wakeup pipes logic out of CConnman and into EdgeTriggeredEvents and WakeupPipes #6007

• Dependent on fix: actually use -socketevents #6027

• Deviations from upstream

  Bitcoin	Dash	Reason
  EventsPerSock is a unordered map of shared_ptrs of Sock wrappers and Events	EventsPerSock is an unordered map of raw socket file descriptors (SOCKET) and Events	Dash implements WakeupPipes, which is constructed and destroyed using an entity outside Sock's control. We need to be able to insert the read pipe raw socket into equivalent of the recv socket set and query for it later on. It would be technically possible, though cumbersome, to wrap the read pipe raw socket in a Sock and overwrite the destructor if it wasn't for the support of edge-triggered modes which have an event-socket relationship, as opposed to level triggered modes, that have a socket-event relationship.
  Sockets passed in an EventsPerSock map will always return with event data for every corresponding entry.	Sockets passed in an EventsPerSock map may return with event data for its corresponding entry.	The behaviour defined for Bitcoin will also be presented in Dash if the socket events mode (SEM) is poll or select. Otherwise, it will behave as described. This is due to the inversion of the socket-event relationship in edge-triggered modes (epoll and kqueue), as alluded to earlier. As edge-triggered modes return events and their corresponding socket (sockets registered through EdgeTriggeredEvents::RegisterEntity() and friends), the EventsPerSock map, will have its contents completely discarded and substituted with the results of {epoll, kqueue}.
  You must have a Sock entity to call Sock::WaitMany()	You can directly access Sock::WaitMany()'s underlying logic through calling Sock::WaitManyInternal() (and access any specific event mode's implementation) without a Sock entity.	This change has been made as Bitcoin's behaviour was to call WaitMany by seeking to the first element to access it. This was possible because the unordered map consisted of Sock entities. As that isn't the case for Dash and WaitMany doesn't truly rely on instance-specific member values of a particular Sock instance (the values it relies on should remain constant throughout program runtime), it can be safely made a static function and that was exactly what was done. It has been named WaitManyInternal() as one of Sock's purposes is mockability and WaitMany() (simply a passthrough to WaitManyInternal()) has been defined as a virtual function.
  Sock's usage of platform-specific APIs is decided exclusively at compile-time.	Sock's usage of platform-specific APIs is determined by what is supported at compile-time and decided at runtime (mostly).	Sock::Wait() (which is transformed into Sock::WaitMany() in this pull request) supported only poll and select and behaved as described for Bitcoin. The described behaviour for Dash was only applicable for CConnman::SocketEvents(). But, as SocketEvents() is being replaced wholesale with WaitMany(), WaitMany() needed to be adapted to mirror SocketEvents() behaviour. This has resulted in changes that now require knowledge of the expected runtime SEM and file descriptor (if using an edge-triggered mode).
  Sock::Wait() and Sock::WaitMany() behave identically	Sock::Wait() will respect the SEM selection argument if it is level-triggered but will fallback to poll or select (determined at compile-time) if the SEM selection is edge-triggered.	Due to the event-socket relationship of edge-triggered modes, they are unsuitable for querying the state of a particular socket. Because of that and a) the unlikelihood of the socket probed being registered with EdgeTriggeredEvents::RegisterEntity() and b) the overhead involved in fetching a list, filtering out for the particular socket we care about and flagging the result, it is more practical to use an LT-SEM instead.

How Has This Been Tested?

Correctness of socket, poll and epoll SEMs were tested using a Debian 12 (bookworm) Docker container with additional logging to ensure the correct syscalls were being made. Correctness of the kqueue SEM was tested using a GhostBSD 23.10.1 (based on FreeBSD 13.2-STABLE) virtual machine with similar additional logging.

Breaking Changes

None expected. Behaviour should remain unchanged.

Checklist

Go over all the following points, and put an x in all the boxes that apply.

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have made corresponding changes to the documentation (note: N/A)
• I have assigned this pull request to a milestone (for repository code-owners and collaborators only)

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

few suggestions. also, kqueue still doesn't work :/

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

few more suggestions

[github-actions]

This pull request has conflicts, please rebase.

[github-actions]

This pull request has conflicts, please rebase.

[kwvg]

Rebased on top of develop (094ceb9) due to dash#6735 with fixes from 2cd3e6b

[UdjinM6]

kqueue seems to be working now 👍

light ACK 67151dc

[github-actions]

This pull request has conflicts, please rebase.

[UdjinM6]

rebase looks clean

re-utACK c611fb0

[PastaPastaPasta]

utACK c611fb0