Async fusion bug: extra fixes and changes

[simonbasle]

• WIP try to fix other fusion issues, doFinally and doAfterTerminate not fuseable
• fix hanging: StepVerifierBuilder cancels upstream AFTER propagating onError in ASYNC mode
• remove doFinally fuseable-related unreachable code
• fix tests: no fusion in doFinally, NONE negotiation in MonoPeekTerminal

[simonbasle]

the rationale for these changes: I started implementing an ArchUnit rule to surface other cases where a Subscriber is a QueueSubscription but doesn't implement onNext (and thus can break ASYNC fusion). It surfaced doFinally.

I tried to fix it and noticed that in the poll() path there was no catching of qs.poll() exceptions.
BUT unfortunately there is no clean way to implement fused doFinally/doAfterTerminate with thrown exceptions. For instance, assuming the following is fused:

 .doFinally(sig -> signals.add("finally"))
 .doOnError(e -> signals.add("onError"))

then the doFinally handler is invoked BEFORE the doOnError (which is contrary to the documented order and the unfused order).

On the other hand, this exploration also surfaced the fact that fused doOnError doesn't catch polling exceptions either, so the doOnError handler above is not even invoked. That one is fixable.

Lastly, in MonoPeekTerminal the afterTerminate handler is in the same situation as doFinally.
The easy solution implemented in this PR: remove Fuseable trait from doFinally and force fusion to be negotiated to NONE in case a MonoPeekTerminal has an afterTerminateHandler.

[reactorbot]

@simonbasle this PR seems to have been merged on a maintenance branch, please ensure the change is merge-forwarded to intermediate maintenance branches and up to main 🙇