Fix async callback failure leading to IllegalArgumentException in SocketChannel.write()

[lorban]

Prototype fix for #11854

This is a slightly modified version of the original proposal that does not require any modification to the Callback interface: introduce a new CancelableCallback class with a static cancel(Callback, Throwable) helper that actually calls failed() on the callback but not before wrapping the given throwable with a private, maker one that is then detected by the CancelableCallback.failed() implementation to discriminate between canceling and failing logic.

[lorban]

See #11857 for an alternative which adds a cancel() method to Callback.

[gregw]

@lorban, whilst I agree the other approach (modifying Callback) is very invasive (and has yet been worked all the way through), I'm not sure this approach is feasible.

The issue is that we frequently wrap Callbacks and such a wrapper between the callback being cancelled and the one being cancelled may not know about cancellation. It would thus see an initial call to fail(Throwable) and would not notice that the exception is specially wrapped. It should pass that on to its nested callback OK, but then it would be within the contract of Callback to become inactive and ignore all subsequent calls to succeeded or failed. Thus there is no guarantee that the ultimate completion signal would be passed on.

I can't see how we can avoid modifying Callback to give wrappers the obligation to pass on both the cancelled event and the ultimate completion (succeeded or failed) event.

Since many of our Callback wrappers are generated by utility methods/classes, this should limit the impact of this. Note that IteratingNestedCallback actually already has abort(Throwable), which a step in this direction.

At the very least, this approach would need a change in the Callback contract to say that multiple failed(Throwable) calls should always be passed on to any nested callback. Once we say that, is it really any different to adding a new cancel method that must be passed on?

[lorban]

Abandoned in favor of #11951