2.x: allow subscribeOn to work with blocking create

[akarnokd]

When running a blocking emission in Flowable.create with subscribeOn, the default behavior of subscribeOn is to schedule downstream requests onto the same thread. Unfortunately, the blocking emission prevents the backing threadpool the create from accumulating that request amount leading to either buffer bloat or dropped emissions till the very end of the sequence.

This PR introduces a nonScheduledRequests parameter to subscribeOn that simply calls the upstream's request() from the caller's thread without scheduling it. The parameter is not exposed to the surface API but the subscribeOn operator does an instanceof check to see if the upstream type is FlowableCreate.

Note that this requires a direct upstream create and any intermediate operator re-enables the default behavior. It is possible to traverse the upstream graph to locate a FlowableCreate but it has relatively high cost and thus penalizing all subscribeOn usages.

Related: #4735

[codecov-io]

Current coverage is 95.70% (diff: 100%)

Merging #4770 into 2.x will increase coverage by 0.09%

@@                2.x      #4770   diff @@
==========================================
  Files           570        570          
  Lines         36711      36713     +2   
  Methods           0          0          
  Messages          0          0          
  Branches       5555       5555          
==========================================
+ Hits          35101      35136    +35   
+ Misses          667        646    -21   
+ Partials        943        931    -12   

Powered by Codecov. Last update 07d24c2...1f12ee6

[JakeWharton]

I understand the change, but I have trouble understand the larger implications of this. Especially when you apply an operator between create and subscribeOn it seems like you're completely out of luck.

[akarnokd]

options:

• ignore the issue
• teach users to have create(..., MISSING).subscribeOn().onBackpressureDrop() instead
• add explicit parameter to subscribeOn() and teach users
• add more extensive lookup

This impacts only those who have busy loop inside create instead of using generate. Users converting other async API or callback style sources are not affected as those don't block the create().

[LalitMaganti]

This seems like a patchwork fix for what is a deeper problem which really should be fixed in a more user-visible manner. It's is very possible that users are using other operators between create and subscribeOn and hardcoding to create seems to be simply deferring the problem to those other cases.

[akarnokd]

Blocking and backpressure don't play nice together. Another fix could forcefully include a Scheduler parameter into create and as such can't be overridden by applying another subscribeOn.