* Extract check for max retry delay to its own method
* Use milliseconds throughout the class and only convert to seconds when
  returning the final visibility timeout
* Use guard clauses in the check_... methods
* Ensure adhering to limits inside the timeout method

Jitter, or randomness in signals, is a common technique for avoiding
calls that fail at the same time to retry at the same time. Therefore
jitter can help avoid the thundering herd problem, where many instances
of the same application all retry at the same time, causing a spike in
load on the system. For example, if a service was down for some reason
and comes back up, all queued events will hit at once and could cause
the service to fail for most events. However, without jitter, the events
will all retry at the same time, causing the same problem. Adding some
jitter (or randomness) to the retry delays result in the events retrying
at different times.

In our implementation, the configuration says how much jitter is used
based on the retry delay. For example, if `retry_jitter_ratio` is set to
0, no jitter will be applied and all events will retry after the usual
retry delay. If it is set to 100, the retry delay will be a random
number between 0 and the retry delay without jitter. If it is set to 20,
the retry delay will be a random number between 80 and 100% of the retry
delay without jitter.

As we are now setting `src` as the default folder, we can just use the
container loop from the mounted `src` volume. Also adjust paths in
README and test script to work from root, rather inside the `script`
folder.

In the upgraded environment with Ruby 3 booting up localstack takes too
long, so some tests relying on it fail before it becomes available.
Solution is just to add healthchecks and to wait for them to be healthy
before starting tests. Also add this for Rspec test action on GitHub to
avoid flaky test runs.