Event Loop shutdown stuck due to uncompleted connect (Fixes #192)

[franz1981]

Motivation:

uncompleted CONNECT_SCHEDULE prevent force closing and issuing IORING_OP_CLOSE, causing a graceful shutdown to complete its quiet period and ignore any later CONNECT completion (at the mercy of OS configuration for connect timeout) due to already shutdown executor.
This will cause the executor to not be able to complete its cleanup because of unclosed channels and making it to hang awaiting an already happened CQE.

Modification:

Allow force close to initiate a close despite the uncompleted CONNECT_SCHEDULE, allowing it to issue a IORING_OP_CLOSE. When the FD close would complete, a later CQE of CONNECT_SCHEDULE on the closed FD will be ignored because its channel is already deregistered.

Result:

Prompt channel close on short timeout (regardless peer presence)

[franz1981]

I've chosen the easy path here: force close just mark the socket to be closed and prompt initiate a deregistration,
without delaying the close operation: when the CQEs of both CONNECT and CLOSE arrive (in this order), they will be ignored because the channel of the FD they refer to is already gone.

[franz1981]

I see that we still have

        final void processDelayedClose() {
            ChannelPromise promise = delayedClose;
            if (promise != null && (ioState & (READ_SCHEDULED | WRITE_SCHEDULED | CONNECT_SCHEDULED)) == 0) {
                delayedClose = null;
                forceClose(promise);
            }
        }

I see no harm to remove CONNECT_SCHEDULED from here as well, although it seems less impactful, or I have still to think to a test case where it can be important.

@normanmaurer any thoughts?