Add a RetryableAspect

[weggert]

This change adds a RetryableAspect. The Retryable aspect allows a method to be annotated with an @Retryable annotation to cause automatic retries in the case of an exception.

This is particularly useful in cases where data is being written in a way where a conflict exception may occur.

The @Retryable annotation takes 3 arguments: maxRetries - The maximum number of retries. Defaults to 0. retryOn - The list of exception classes to retry on. Defaults to all. retryDelayMillis - The delay between retries in millis. Defaults to 0.

The @Retryable annotation works in much the same way as the @CircuitBreaker and @PerformanceMonitor annotations, and so all of the same caveats apply. Trying to call an @Retryable method from within the same instance will bypass the proxy and result in no retrying.

[jonm]

I like it. Will there be a way going forward to permit alternative retry schedules (e.g. exponential back off)? Doesn't have to be implemented now if we know how to add that without breaking backwards compatibility.

[joercampbell]

Yeah - its a good first step... I talk to wally a little about making this use the ServiceRetrier under the hood instead of re-implementing that, which will mean expanding some mechanisms of how that class works in Core right now. I think the net when we are done here is an annotation that allows you to make a service as Retryable and some fairly slick configuration about what constitutes the 'triggers' for retying a given call.

[joercampbell]

Assume that retryPolicy collects the singular settings that we are capturing as a method for controlling the logic of the retry? Do you have a small code example you could share as I am not as familiar with what spring has for retries.