Feature/rate limiter publisher

[OlegDokuka]

In this PR I want to introduce rate-limited request coordinator which basically prevents direct Long.MAX_VALUE propagation.

I'm considering moving this part to "addons" and instrument RSocket via plugin API.

For now, leave it in this for pre-reviewing

[yschimke]

I thought this was already directly possible based on optional Spring Reactor operations? I hate the infinite then cancel default mode of Reactor, but why the need to implement yourself?

[OlegDokuka]

@yschimke I consider that as a replacement for LimitableRequestPublisher which does internaRequesN(Long.MAX_VALUE) and then do coordination based on the external request size. In case external consumer requests Long.MAX_VALUE it can lead to -> #514. This is still an issue. Previously, I was not able to end up with efficient enough and properly tunned request coordination algorithm, and do not think it makes any sense (see Flux#flatMap request coordination between producers. You may find that it is based on the prefetch and subsequent additional requests over the time). Thus, my idea is to get rid of LimitableRequestPublisher, so it will not bring any additional synchronization overhead during runtime, and in case of need, provide Plugin with that functionality. Note, default Reactor#limitRate is too overhead. It creates SPSCArrayQueue (in fact there are no reasons to do that) and then introduces tasks rescheduling over Schedulers.immediate, so it leads to function invocation overhead

[yschimke]

Thanks for the explanation. Is this worth opening an issue with reactor as well?

[OlegDokuka]

I think, I'm going to port it eventually, but it worth, indeed

[yschimke]

This doesn't appear to match the logic on line 56. Integer vs Long MAX_VALUE. It's hard to intuit whether that's intentional because there are multiple fields. Maybe some comments to clarify what max values are used.

[robertroeser]

LTGM - I'd like to merge this in to start testing if its ready to go.