Description
Use latestReleaseDate to determine what repos to harvest DOIs for. Also added some logic to not run into Zenodo rate limits. The harvesting flow will work like this:

1. We harvest all GitHub-Zenodo DOIs once, using the existing updateDOIs endpoint.
2. When new GitHub releases are created, we are notified via GitHub apps; we stored the release date on the workflow.
3. We will then call this endpoint daily, but only checking workflows that have had releases in the last 2(TBD) days.

This PR adds a query parameter that specifies how far back to look for GitHub-Zenodo DOIs.

A companion PR for dockstore-deploy will be created to do step 3 daily.

On the rate-limiting, I could not find a library that implements client-side rate limiting based on the headers. I played for a bit with https://github.com/bucket4j/bucket4j, but the Zenodo refresh and/or rate limits don't seem to match be exactly as documented, so when I set up a token bucket, I would end up running into rate limits from Zenodo.

Review Instructions

1. Turn on Zenodo-GitHub integration for a GitHub repo with a workflow in Dockstore.
2. Do a GitHub release for that repo
3. The next day, check that the DOI is visible in Dockstore.

Issue
SEAB-6688

Security and Privacy

If there are any concerns that require extra attention from the security team, highlight them here and check the box when complete.

• Security and Privacy assessed

e.g. Does this change...

• Any user data we collect, or data location?
• Access control, authentication or authorization?
• Encryption features?

Please make sure that you've checked the following before submitting your pull request. Thanks!

• Check that you pass the basic style checks and unit tests by running mvn clean install
• Ensure that the PR targets the correct branch. Check the milestone or fix version of the ticket.
• Follow the existing JPA patterns for queries, using named parameters, to avoid SQL injection
• If you are changing dependencies, check the Snyk status check or the dashboard to ensure you are not introducing new high/critical vulnerabilities
• Assume that inputs to the API can be malicious, and sanitize and/or check for Denial of Service type values, e.g., massive sizes
• Do not serve user-uploaded binary images through the Dockstore API
• Ensure that endpoints that only allow privileged access enforce that with the @RolesAllowed annotation
• Do not create cookies, although this may change in the future
• If this PR is for a user-facing feature, create and link a documentation ticket for this feature (usually in the same milestone as the linked issue). Style points if you create a documentation PR directly and link that instead.