Support remaining date based ChronoUnit enumerations for @Retry annotation

[AlexXuChen]

As per #193 (comment):

We use java.time.Duration to calculate the difference between effective delay and max duration when passed as member values in the @Retry annotation. According to the implementation of Duration.plus, any date based ChronoUnit enumeration excluding DAYS (e.g. WEEKS, MONTHS, YEARS, etc..) will throw an UnsupportedTemporalTypeException.

Seeing that this is a limitation to the current implementation for @Retry diagnostics, (where we simply ignore these cases), there are 2 possible solutions:

1. Have a wrapper to handle every date based case
2. Wait for java.time.Duration to support date based enumeration(s)

[rgrunber]

Would this work ?

import java.time.temporal.ChronoUnit;
public double getDurationInNanos (ChronoUnit unit, long unitValue) {
  double seconds = (double) unit.getDuration().getSeconds();
  int nanos = unit.getDuration().getNano();
  return (seconds * 1000000000 * unitValue) + (nanos * unitValue);
}

jshell> getDurationInNanos(ChronoUnit.YEARS, 9) > getDurationInNanos(ChronoUnit.DECADES, 1)
$5 ==> false
jshell> getDurationInNanos(ChronoUnit.YEARS, 11) > getDurationInNanos(ChronoUnit.DECADES, 1)
$7 ==> true

[AlexXuChen]

Would this work ?

Actually seems so! I assume this is because it doesn't use the Duration class.

[rgrunber]

We basically avoid any helper methods and just convert everything straight into the most common unit, nanoseconds.

There might be some optimization that could be done where we compare everything MILLIS or below in nanos and everything else in seconds. Ultimately that just saves us an extra 9 digits in case the input values get crazy, but hopefully we don't have to be that resilient for now.

[AlexXuChen]

We also have https://docs.oracle.com/javase/8/docs/api/java/time/Duration.html#getNano--, but we may run into the same issue as before.