Limit retry attempts in SIRI-SX updater

[vpaturet]

Summary

The SIRI-SX updater retries an indefinite number of times when it fails to retrieve data from the SIRI-SX server. This approach is problematic when using a scheduled thread pool where each task is expected to complete briefly and return the thread to the pool.
This PR adapts the retry logic so that SIRI requests are retried a limited number of times during each polling.

Note: The Apache HTTP client library retries by default all idempotent HTTP operations (GET, ...) for a limited list of IOExceptions (see https://www.baeldung.com/java-retrying-requests-using-apache-httpclient).
The HTTP request sent by the SIRI-SX updater is a POST operation and is not retried by default. This is the correct behavior since this request is indeed not idempotent: the server replies with the list of new messages published since the previous request.

Issue

No

Unit tests

Added unit tests

Documentation

No

[codecov]

Codecov Report

Patch coverage: 51.02% and project coverage change: +0.02% 🎉

Comparison is base (5aa96ef) 65.90% compared to head (7df26a6) 65.93%.
Report is 10 commits behind head on dev-2.x.

Additional details and impacted files

@@              Coverage Diff              @@
##             dev-2.x    #5264      +/-   ##
=============================================
+ Coverage      65.90%   65.93%   +0.02%     
- Complexity     14783    14804      +21     
=============================================
  Files           1770     1773       +3     
  Lines          68680    68743      +63     
  Branches        7276     7278       +2     
=============================================
+ Hits           45264    45324      +60     
  Misses         20932    20932              
- Partials        2484     2487       +3     

Files Changed	Coverage Δ
...r/ext/siri/updater/SiriETHttpTripUpdateSource.java	0.00% <0.00%> (ø)
...entripplanner/ext/siri/updater/SiriHttpLoader.java	0.00% <0.00%> (ø)
...pentripplanner/ext/siri/updater/SiriSXUpdater.java	0.00% <0.00%> (ø)
...tripplanner/framework/retry/OtpRetryException.java	50.00% <50.00%> (ø)
...entripplanner/framework/retry/OtpRetryBuilder.java	90.47% <90.47%> (ø)
.../org/opentripplanner/framework/retry/OtpRetry.java	90.62% <90.62%> (ø)

... and 5 files with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[t2gran]

Just minor stuff. I looked at the resilience4j as you mentioned, but it look a bit overkill for this :-)