ENT-14195 1. Refactored cf-reactor event handling with one unified interface

[victormlg]

Rather than exposing the raw file-descriptor bookkeeping required for select(2), we introduce a unified interface that serves both the reactor-plugin and event-driven code paths. This is achieved by encapsulating all relevant state in a context struct, ReactorContext:

typedef struct ReactorContext
{
    int *all_fds; // heap allocated array of fds
    size_t all_fds_capacity; // total number of fds. number of nova fds + number of event fds 
    size_t num_nova_fds; // this is returned by the reactor-plugin
    size_t num_fds; // this is 1
    // the first (num_nova_fds - 1) slots in the array are reserved for the reactor-plugin, the last one is reserved for the event driven code.

    fd_set readfds;
} ReactorContext;

• ReactorContextInitialize(): initializes the reactor-plugin and event-driven code. Wraps ReactorNovaInitialize()
• ReactorContextSetupFileDescriptors(): populates readfds with the file descriptors to monitor, prior to the select() call.
• ReactorContextHandleEvents(): iterates over the file descriptors and dispatches the appropriate action based on which ones were signaled as ready. Wraps ReactorNovaHandleTimeout and ReactorNovaHandleEvents().
• ReactorContextFinalize(): releases the daemon's associated resources. Wraps ReactorNovaFinalize().

[larsewi]

What if we stored FDs in a dynamic list instead (e.g., Seq)? Furthermore, maybe the FD itself could be wrapped in a struct with flags to tell what type of FD it is, and whether or not it is owned by any external plugin.

[larsewi]

Did we not recently remove the watcher code you are referencing here?

[larsewi]

Seems like this belongs in reactor_context.h. What is the reason for having it here?