ci: reduce ccache size on GHA runners #35176

The GHA cache backend has a 10 GB per-repository limit, so jobs that save multiple 2 GB ccache entries can evict each other before slower jobs have a chance to reuse their caches. This was observed in #35024.

Set CCACHE_MAXSIZE to 500M only for jobs using GitHub-hosted runners, including matrix entries that explicitly opt into GHA. Keep the 2G limit for Cirrus runners, where the larger cache does not compete for the same constrained GHA cache quota.

<!-- *** Please remove the following help text before submitting: *** Pull requests without a rationale and clear improvement may be closed immediately. GUI-related pull requests should be opened against https://github.com/bitcoin-core/gui first. See CONTRIBUTING.md -->

<!-- Please provide clear motivation for your patch and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly: * Any test improvements or new tests that improve coverage are always welcome. * All other changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`). Contributors should note which tests cover modified code. If no tests exist for a region of modified code, new tests should accompany the change. * Bug fixes are most welcome when they come with steps to reproduce or an explanation of the potential issue as well as reasoning for the way the bug was fixed. * Features are welcome, but might be rejected due to design or scope issues. If a feature is based on a lot of dependencies, contributors should first consider building the system outside of Bitcoin Core, if possible. * Refactoring changes are only accepted if they are required for a feature or bug fix or otherwise improve developer experience significantly. For example, most "code style" refactoring changes require a thorough explanation why they are useful, what downsides they have and why they *significantly* improve developer experience or avoid serious programming bugs. Note that code style is often a subjective matter. Unless they are explicitly mentioned to be preferred in the [developer notes](/doc/developer-notes.md), stylistic code changes are usually rejected. -->

<!-- Bitcoin Core has a thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. -->

<!--e57a25ab6845829454e8d69fc972939a-->

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

<!--021abf342d371248e50ceaed478a90ca-->

Reviews

See the guideline for information on the review process.

If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

<!--174a7506f384e20aa4161008e828411d-->

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #35144 (ci: migrate linux CI jobs to namespace by willcl-ark)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

<!--5faf32d7da4f0f540f40219e4f7537a3-->

Extra GHA cache seems very cheap according to this page:

Cache size Monthly cost (if fully utilized) 50GB $2.80 200GB $13.30 1000GB $69.30

And IMO would be the better option all round. Let me know if we don't want to buy more cache space from GH, and I'll undraft this.

One advantage of this change though, might be that forks get "better" GHA cache hitrates (at our own expense though, to be clear).

200GB $13.30 1000GB $69.30

Concept ACK.

Yeah, not sure how easy it would be to set up billing for this, but if it is possible, going for 200 GB (or more) would be nice.

Cache size Monthly cost (if fully utilized) 50GB $2.80 200GB $13.30 1000GB $69.30

And IMO would be the better option all round.

I concur.

Well, if we find someone willing to shell out the whole $13/month for it, an admin will want to visit and configure billing information on https://github.com/organizations/bitcoin/settings/billing/payment_information

Then, I think, they need to "set a budget" at https://github.com/organizations/bitcoin/settings/billing/budgets for actions to increase what can be spent on actions.

It's unclear to me whether https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-cache-settings-for-your-repository is needed too, I think a bit of trial and error to work out which knobs we need to press could be in order...