Consider replacing got with native fetch

Once https://github.com/badges/shields/pull/11070 is merged and we are deployed on node 22, an interesting option becomes available to us.

We could replace got with native fetch.

I don't think this is super high priority because there is nothing _wrong_ with got. It is entirely fit for purpose and actively maintained. However, our HTTP client is in the critical path for basically every request we serve (aside from static badges) so any performance improvement we could make here could reduce our resource usage across the board. However I don't really know how impactful it would be.

Native fetch should offer better performance because it is based on undici, whereas got uses the legacy http(s) modules. A migration would have a lot of implications. One of them is that we'd have to upgrade to nock 14 for mocking (currently we've got some issues with this and we're still on nock 13). Another is that we expose got's API to the service layer so many individual badges use got's API to do things like set headers on requests, set timeouts, etc. There is a substantial switching cost if we want to migrate.

When we migrated from request to got in 2021, we did try out node-fetch (which basically has the same API but was a userspace implementation and not based on undici, so didn't have the performance advantages of native fetch). We ended up reverting it, but there is some code in https://github.com/badges/shields/pull/6914 that may or not be helpful to look at if we decide to do this.

Start by reviewing PR 11070 for the Node 22 deployment context and PR 6914 for the earlier node-fetch migration. Inventory how the service layer and individual badges use got’s API, and inspect the current nock 13 mocking issues. Done means the implications are resolved and the HTTP client can be migrated to native fetch without breaking badge requests or tests.

Written by the indexing model from the issue text.