[chore/bugfix] Serve + throttle publickey separately from rest of ActivityPub API

[tsmethurst]

Description

If this is a code change, please include a summary of what you've coded, and link to the issue(s) it closes/implements.

If this is a documentation change, please briefly describe what you've changed and why.

This pull request updates some of our routing code to serve the /users/:username/main-key ActivityPub endpoint separately from the other AP endpoints, in order to apply separate throttling + cache policies on it (public cache with lengthy max-age).

The reason for this change is that when a status is federated from GtS to a Mastodon server, Mastodon always makes a request to get the main-key again (mastodon/mastodon#19217). If it can't get the main-key because of throttling or some other issue, the status won't be accepted by that Mastodon server, leading to spotty federation.

By throttling the main key separately from other AP endpoints, there should be less chance of a post not federating to mastodon due to server unavailability.

Finally, the PR also includes changes to the nginx advanced documentation, to provide the option of allowing nginx to cache main-key responses in addition to webfinger responses.

Checklist

Please put an x inside each checkbox to indicate that you've read and followed it: [ ] -> [x]

If this is a documentation change, only the first checkbox must be filled (you can delete the others if you want).

• I/we have read the GoToSocial contribution guidelines.
• I/we have discussed the proposed changes already, either in an issue on the repository, or in the Matrix chat.
• I/we have performed a self-review of added code.
• I/we have written code that is legible and maintainable by others.
• I/we have commented the added code, particularly in hard-to-understand areas.
• I/we have made any necessary changes to documentation.
• I/we have added tests that cover new code.
• I/we have run tests and they pass locally with the changes.
• I/we have run go fmt ./... and golangci-lint run.

[NyaaaWhatsUpDoc]

We could still provide throttling for it, but give it a separate throttling middleware instance similar to how we handle federated + client APIs. What do you think?

[tsmethurst]

We could still provide throttling for it, but give it a separate throttling middleware instance similar to how we handle federated + client APIs. What do you think?

Yeah I'm up for that :) I'll change it.