Add blocklisting for recursive on-demand domains

[aarongable]

Add BlockedOnDemandLabels, a list of strings, to the WFEs config. This new config item will be populated by a list of subdomain labels that frequently appear in just-in-time requests for certificates as a result of recursive automated crawler activity.

For example, a vulnerability-seeking bot might see a cert for example.com in CT, and attempt to access asdf.example.com. The webserver receiving that request uses us to just-in-time issue a cert for that name, when then appears in CT. Moments later, the crawler attempts to access asdf.asdf.example.com, and the cycle repeats. We don't want to issue certs for names that look like they result from this process.

Specifically, block new-order requests for requests that have at least four domain labels; and either two identical blocked labels in a row, or any three blocked labels in a row.

Fixes #8645
IN-12292 tracks the corresponding config changes

[github-actions]

@aarongable, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values.

[jsha]

This looks fine, though the logic inside looksLikeRecursiveJITRequest feels slightly messy, with edge cases and chances for off-by-one.

It seems like you could do better by ranging over the slice, incrementing a score for each blockedLabel. If the score reaches 3, error; if a non-blockedLabel is seen, score is reset to 0.

The "two in a row" check would remain mostly unchanged.

Also, I think "JIT issuance" is not a broadly used term. Since we believe most affected subscribers are using Caddy, it would be slightly nicer for the error message (and the code) to say "on-demand issuance", which is closer to the term used in Caddy.

Both of these pieces of feedback are optional.

[aarongable]

I like those points, I've uploaded a new version with a simpler loop and using the "on-demand" language instead of "just-in-time".

[jsha]

Approving module to the one tweak above; once you get a second approval you can go ahead and merge without waiting for my reapproval.

[beautifulentropy]

Looks great, just one nit.

[aarongable]

Merging on one approval, as per prior approval from a second reviewer noted above.