[feature] request blocking by http headers

[NyaaaWhatsUpDoc]

Description

• adds new HeaderFilter() middleware to filter requests by their header content
• adds new database methods to get, store, delete and match against request header filters
• adds new cache types for both allow and block type header filters
• adds new headerfilter subpkg which handles the actual compiling of in-memory request header filters (header keys to value matching regular expressions) + stat collection
• adds new admin API endpoints (with matching swagger docs) to manage allow / block header filters
• adds new "advanced-header-filter-mode" configuration variable which matches the "instance-federation-mode" variable in how it functions re: allow vs. block modes
• add new /docs/admin/header_filtering_modes.md documentation laying out the logic of the http request filtering modes

Checklist

• 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.

[tsmethurst]

This can probably be dropped, if we're going to use prometheus/otel metrics for this then we can use a counter for this instead when we get around to it.

[NyaaaWhatsUpDoc]

oh I was just going to return this as a counter value, as I'm pretty sure that's what it uses under the hood is atomic ints etc. the plan is to make that stats function export Prometheus compatible data at some point. also this way I have some stat collection enabled required for one of the milestone bulletpoints

[tsmethurst]

The way counters work in OTel is I think to just call Add(i) on the counter when a value must be incremented, and let OTel handle the rest; you don't actually need to keep track in the application of the counter's current value afaik. That's one thing that makes OTel so nice :) I mean we could implement it ourself and serve that raw value, but it seems unnecessary unless there's some specific benefit / bug workaround in doing so, I think.

[NyaaaWhatsUpDoc]

gotcha. maybe in the tracing / metric package i'll wrap it so it works with our enabling / disabling mechanism (otherwise this will make it a hard dependency in all cases)

[NyaaaWhatsUpDoc]

so for now i've kept-in an initial statistics tracking implementation, but i have rejigged the header matching so the matched header key and regular expression are returned which should make it easier to instrument with otel in the future. see: eaa29f9

[tsmethurst]

It's looking great! Coming along nicely!