1.x: request rebatch operator

[akarnokd]

This is a follow-up on #3964 but with a separate operator on Observable.

[DavidMGross]

@beta? @experimental? @SInCE?

[akarnokd]

Added.

[zsxwing]

👍

[akarnokd]

@abersnaze, @stealthcode you had some use cases for this, any objections?

[abersnaze]

the reuse of the observeOn is interesting but couldn't it be done without the allocation of a queue?

[akarnokd]

If the downstream request is unbounded and the downstream has caught up then the queue can be skipped. In this case, observeOn can't be reused anymore and a custom drain logic has to be implemented.

Otherwise, the upstream emissions have to be stored temporarily for an underrequesting downstream.

[stevegury]

👍

[stealthcode]

I know that @abersnaze still had reservations about this. I think that this should not be using observeOn.

[stealthcode]

My concern is this - If @abersnaze implemented the batching functionality then why wouldn't we use that? The queue in observeOn scheduling creates a layer of indirection that seems unnecessary.

[akarnokd]

Remember, this started out as a change to observeOn to not ignore the immediate scheduler but people wanted this behavior exposed behind a proper name.

[stealthcode]

Thanks for reminding me of the context of this work. It seems like we have 2 implementations for the same functionality. I think @abersnaze and I agree that the 2 features of request batching and request valve type functionality could be composed. However I think that using observeOn for this functionality is not necessarily the best way to accomplish this.

[stealthcode]

I personally would be okay with either implementation. I think observeOn is a nice choice because of the request management but would prefer it more if there wasn't a queue. But realistically I think the choice is fine.

Also it's interesting to note that users are gravitating more and more to taking direct control over the requester-producer interactions.

[abersnaze]

For example this PR does something similar but exactly n (could be modified to have optional 25%) and without a queue #3781.