Disallow implicit blocking operators of Project Reactor's Flux

[Ernir]

Problem

Excessive blocking is a known pitfall in reactive programming. Some of Reactor's blocking operators are quite explicit about their behavior, e.g. Mono#block and Flux#blockFirst, leaving no doubt that the operation is in fact blocking.

This does not apply to two of the convenience methods exposed by Reactor's Flux, Flux#toStream and Flux#toIterable. These operators are documented to block, but this is not apparent from the method signature. It is easy to miss that the operation is blocking despite any potential lazy consumption of the resulting Stream or Iterable.

Description of the proposed new feature

• Support a stylistic preference.
• Avoid a common gotcha, or potential problem.
• Improve performance.

We should rewrite the problematic operators in terms of explicitly blocking operators, highlighting actual behavior.

Focusing first on the stream, I would like to rewrite the following code:

flux.toStream()

to:

flux.collect(toList()).block().stream()

To be determined what a general rewrite for Flux#toIterable would look like, or if this is actually desirable.

Considerations

• The methods in question have overloads detailing their usage. We could consider allowing those, assuming that those operators are less likely to be used accidentally. Compare with the existing FluxFlatMapUsage rule.
• The problematic methods being convenience methods, the proposed solution is more verbose than the original.

Participation

• I am willing to submit a pull request to implement this improvement.

Willing, sure! Less sure on able. Would be happy to see anyone else submit a pull request to this effect. :D

[Stephan202]

See #472 (comment) for some discussion on the approach to take here.

[Ernir]

Thanks @benhalasi , @rickie , @Stephan202 !