Improve error handling in NIO server.

[glbrntt]

• Adds a user-configurable error handler to the server
• Updates NIO server codegen to provide an optional error handler
• Errors are handled by GRPCChannelHandler or BaseCallHandler,
  depending on the pipeline state
• Adds some error handling tests
• Tidies some logic in HTTP1ToRawGRPCServerCodec
• Extends message handling logic in HTTP1ToRawGRPCServerCodec
  to handle messages split across multiple ByteBuffers (i.e. when a
  message exceeds a the size of a frame)

[MrMage]

Amazing work! This is just great, and brings the server part quite a bit closer to production-readiness. Thank you so much!

I mostly have nits and clarification questions. Feel free to dispute any, especially those that end with a question mark ;-)

[MrMage]

Two more thoughts:

1. Should we have a CollectingServerErrorDelegate (similar to CollectingChannelHandler) in our tests and assert that the error delegate is sent the expected of errors?

2. It might be nice to provide some more error context to ErrorDelegate, e.g. which Server/CallHandler/etc. (and the corresponding method path) has caught the current error, so we know more precisely where the error occurred.

3. might require too many modifications to be incorporated into this PR, though. WDYT?

[glbrntt]

1. Should we have a CollectingServerErrorDelegate (similar to CollectingChannelHandler) in our tests and assert that the error delegate is sent the expected of errors?

This should be pretty straightforward to do. I'll include this in the next revision.

2. It might be nice to provide some more error context to ErrorDelegate, e.g. which Server/CallHandler/etc. (and the corresponding method path) has caught the current error, so we know more precisely where the error occurred.

This is potentially useful for us. However, with the new enum of error cases, each one is only thrown in one or two places so I think we can leave this for another day.

[MrMage]

👌 work overall! Just a few minor changes left.

This is potentially useful for us. However, with the new enum of error cases, each one is only thrown in one or two places so I think we can leave this for another day.

The advantage of this would be that we would know the name of the gRPC method that caused the failure (e.g. "Get/Collect/Expand/Update"). Let's leave this for the future, but please add a TODO asking for this to ServerErrorDelegate.

[MrMage]

Looking good! @glbrntt, I think all that's left would be comments from you on the two remaining unresolved discussions and fixing the merge conflict.

[MrMage]

Approved, save for the missing commas.

Again, terrific work!

[glbrntt]

Looks like we have a fatal error in the NIO Web tests:

Test Case 'NIOServerWebTests.testUnaryLotsOfRequests' started at 2019-02-26 13:42:02.497
Fatal error: Trying to remove task, but it's not in the registry.: file Foundation/URLSession/TaskRegistry.swift, line 76

@MrMage given these tests weren't included in LinuxMain before do you have any objections to just disabling the failing test (and opening an issue) for now?

[MrMage]

Looks like we have a fatal error in the NIO Web tests:

Test Case 'NIOServerWebTests.testUnaryLotsOfRequests' started at 2019-02-26 13:42:02.497
Fatal error: Trying to remove task, but it's not in the registry.: file Foundation/URLSession/TaskRegistry.swift, line 76

@MrMage given these tests weren't included in LinuxMain before do you have any objections to just disabling the failing test (and opening an issue) for now?

Thanks for spotting that! I agree with disabling them for now and opening an issue. This is probably not even related to our code directly, but rather due to a flaw in the Linux implementation of URLSession.