[core][binance][livecoin] unified retry and rate limit proof of concept

[walec51]

work in progress - wait a moment with the review

[walec51]

I will be contributing some of this code to https://github.com/resilience4j/resilience4j so this PR will get slimmer

see issues:

• New Annotation to combine different Annotations resilience4j/resilience4j#643
• Weight support in RateLimiter resilience4j/resilience4j#642

[badgerwithagun]

This looks fantastic at first look. Feel free to @ me for a review when done - I may want to pull support into xchange-stream.

[walec51]

@badgerwithagun I'm trying to push some of the features done here to resilience4j, currently you can help by stating your support here: resilience4j/resilience4j#643 ;)

[walec51]

@timmolter if you have some time please review this along with this documentation https://github.com/knowm/XChange/wiki/Implementing-resiliency-features

resiliency features are now configured in *Raw classes - previously I did it using annotation on proxy interfaces but my new annotation scheme was not accepted by the resilience4j project so I removed this way of doing things

[badgerwithagun]

@walec51 - one thing I've been wondering about recently is whether it would be possible to move XChange to a non-blocking core, allowing (optional) call semantics like:

exchange.getMarketDataService()
    .getTickerFuture(currency)
    .thenAccept(ticker -> {
      // Use the ticker
    });

The trick here being that this API would allow something like netty to be used, meaning no thread needs to block while the socket is waiting for a response from the exchange. After xchange-stream is merged, most of the wiring necessary to do this will already exist.

The reason I mention it here is to ask: does the solution you've been working on allow a promise-like approach to rate limiting which doesn't require a thread block? I understand resilience4j does have non-blocking support via the use of a small ScheduledExecutorService.

Obviously I'm not worried about supporting it now, it'd just be good to be able to see a migration route later.

[walec51]

@badgerwithagun resilience4j has some support for non blocking APIs but making XChange reactive would be a total rewrite of the library and all of its modules (additional APIs, totally different implementations, replacing mmazi/rescu with a less trivial proxy client library)

I don't see this happening any time soon and this should not be discussed in this PR

[walec51]

@timmolter is this PR ok with you? can I merge it?

[timmolter]

yeah, looks good. Too bad they won't accept your PR. :(