GHA runners collector

[njasm]

WIP. Don't merge yet. depends on landing of #12 to rebase.

Will close #11

Still need some cleaning, and eventually move some common code (with Rate limit collector) to a new module. ex. http client code

• Added config var MONITORBOT_RUST_ORG_TOKEN that needs to contain the org's repo scoped token to be used to query GHA runners status
• Added config var MONITORBOT_RUNNERS_REPOS that will contain the org's repositories to track GHA runners. multiple repos allowed as long as they are under the same org's umbrella. ex syntax: rust-lang/rust,rust-lang/cargo,rust-lang/rust-clippy
• Added config var MONITORBOT_GHA_RUNNERS_REFRESH that's the refresh rate frequency (in seconds) to update the cached data about the runners statuses. default value is currently 120

current output:

[njasm]

this last push already have a fix for #14

• I've added a mechanism that every time monitorbot starts and before hitting the api with the token for the username, we first check if the token is flagged (aka: no more api requests available to make at present time) or if we still have requests allowed to make. if at least one is flagged, the application starts but the collector fires a background task to check if we can initialize the uninitialized metrics for the flagged tokens. eventually all tokens will be available as metrics to be scraped.

• As soon as no more uninitialized metrics exist from flagged tokens that background task returns.

• With the above changes, I've also put the metric's vec field behind an Arc<Rwlock<<>>.

@pietroalbini Sorry for mixing both issues in one PR, but since I was refactoring some minor things I took the chance and went forward and introduced this mechanism for the issue #14. (I got excited and kept writing code 😅)

If you feel it's too much or you prefer to review two independent PRs, feel free to ping me in zulip or here, and when I have the time I'll try to split this one into two or as you see fit.

thanks!

[pietroalbini]

Thanks for the PR! Splitting this into two separate PRs would indeed be useful: I don't have a lot of time this week, and while I can probably review a smaller PR without issues this would take too much time.

[njasm]

Ok, will split those into two separate PRs when I get a change. But right know with Xmas things are a little crazy to get some time free, so I can't really compromise on a time frame for those for the very near future right now.

[njasm]

this PR is superseded by #15