Remove usage of subtle.ConstantTimeCompare in validation

[aarongable]

While constant-time comparison is important in cryptographic algorithms, that's not what we're doing here. The validation random token is not intended to be secret in the same way as (say) a private key is: it's just meant to be random enough that it's unlikely to exist in DNS or on a webserver by chance. Possession of the random token does not give an attacker any advantages; they still need to control the domain itself, at which point they could get a random token of their own. Using subtle.ConstantTimeCompare is overkill and sets a bad example for places that truly do need to use it.

[jsha]

Boulder is server software, validation is asynchronous

I'd like to remove both of these as rationale. Timing attacks can absolutely be exploited across the network, and I strongly suspect that's true even with the asynchronous polling aspect. Googling around, here's some research presented in 2024: https://portswigger.net/research/listen-to-the-whispers-web-timing-attacks-that-actually-work. I haven't read that one yet, but I've also seen past research demonstrating how to do precise timing measurement across the network.

IMO, the rationale for doing this is just that the validation token is not meant to be a secret. The purpose of the validation token in the protocol is that it's very unlikely to exist on a website (or in DNS) by happenstance. Guessing a validation token does not grant an attacker any privilege.

The single-use nature of the tokens is probably also a reason why timing isn't so important, but fundamentally the reason for this change is that secrecy of the token is not part of its security properties.