[DRAFT]: Make auto updates rate-limit aware

[TomJo2000]

This PR aims to make the auto-update workflow rate-limit aware in order to avoid future shadowbans of @termuxbot2 for just doing its job.

In this current state it only implements basic debugging functionality by printing out the .resources.core table of the rate limit query API response which contains the limit_(int), used_(int), remaining_(int) and reset_{(unix_epoch)} keys.

For local testing I have generated a fine grained access token for GitHub, which I am sourcing from gh.env inside the root directory of the git repo.
(This token only has read permissions to the rate-limit API endpoint, I may need to replace it for further testing)

# file: gh.env
export GITHUB_TOKEN='<your_github_token_here>'

The token is obviously passed in as part of the environment in the CI, so this file exists just for local testing.
Speaking of which, my local testing setup consists of running:

./scripts/run-docker.sh ./scripts/bin/update-packages '@all'

Which simulates a full auto update run.
(It also eats through the rate limit quite fast, which is why I'm opening this PR now, since I need to wait an hour to do more testing)

[twaik]

1. I am pretty much sure we should not spam logs with ratelimit status. The most of ratelimit consuming job is done in _fetch_and_cache_tags which invokes a lot of simultaneous requests to github (to save some CI time by avoiding requesting tags one by one). And not every single package invokes github rest api. I see at least two ways to optimize it.
   a. Moving ratelimit checking to termux_github_api_get_tag.
   b. Invoking ratelimit check every 50 packages.
2. termux_repology_api_get_latest_version creates repology metadata file on the first invocation and after this simply reuses it. We can do similar thing for ratelimits. We can cache the used field of github ratelimit reply and decrement it on every github request. This counter will be used to report null or current version of package when ~50 requests are remaining. AFAIK null should make tag checker report the current version as latest without throwing errors.

[TomJo2000]

I know we don't want to spam logs, I'm not suggesting this is ready to merge in this state, this is an initial draft.

If you got any code suggestions do feel free to put them in here, or push them to my branch, or I can move the branch over to this repository if that is easier in terms of workflow.

[twaik]

I can try this a bit later, currently I should go to sleep.

[TomJo2000]

Yeah I'm about to as well, I just wanted to push this before I do.

[TomJo2000]

Alright I did a full run now that the limit reset for me and it looks like it takes ~820 API calls for the full auto-update cycle.

[TomJo2000]

That limit is shared globally between all CI runs, and as such also resets globally for all CI runs.
We could probably make it idle or reschedule for after the next reset if there isn't even API limit remaining is the current time window.

(That limit being 5000 per hour)

[thunder-coding]

I think the main reason we are getting rate limited is because we aren't slowing down our api requests. See https://docs.github.com/en/rest/using-the-rest-api/rate-limits-for-the-rest-api?apiVersion=2022-11-28#about-secondary-rate-limits, maybe we should actually fix this than using such workarounds