`NIOSSLHandler`: behave sensibly on `close(mode: .output)`

[felixschlegel]

Motivation

If NIOSSLHandler receives close(mode: .output) or close(mode: .input), it ignores them, optionally failing their promises. This is weird behaviour. It should do better.

Modifications

• flush outstanding messages on NIOSSLHandler.close(mode: .output)
• close SSL Connection on NIOSSLHandler.close(mode: .output)
• support closing the input of NIOSSLHandler when used as a server with ChannelOptions.Types.AllowRemoteHalfClosureOption enabled
• trigger TCP close when NIOSSLHandler.state == .inputClose
• write integration tests to verify the behaviour

Warning: This PR relies on EmbeddedChannel supporting ChannelOptions.Types.AllowRemoteHalfClosureOption, which is currently not possible and proposed as a Patch to swift-nio

Note: I have removed a lot of whitespace, so consider selecting Hide Whitespace in the GitHub Files Changed tab

[felixschlegel]

Hey @Lukasa ,

I have implemented your requested changes and added the buffering of closeOutput when we are still in state = .handshaking / .additionalVerification.

I still have a couple of open questions for this PR:

• should we also support scheduledShutdown for close(mode: .output) (see the normal close mode for reference)
• what if the downstream ChannelHandler does not support close(mode: .output)? At the moment we just invoke context.close(mode: .output) hoping for the next ChannelHandler not to fail

Best regards, -Felix

[Lukasa]

@swift-server-bot add to allowlist

[Lukasa]

should we also support scheduledShutdown for close(mode: .output) (see the normal close mode for reference)

No, scheduled shutdown is waiting for us to get a CLOSE_NOTIFY from the remote peer. In this mode, we don't expect one.

what if the downstream ChannelHandler does not support close(mode: .output)?

Then the partial close fails and the user should upgrade to full close.

[felixschlegel]

@swift-server-bot test this please

[yim-lee]

@swift-server-bot test this please