WFE: Correct Error Handling for Nonce Redemption RPCs with Unknown Prefixes

[beautifulentropy]

Fix an issue related to the custom gRPC Picker implementation introduced in #6618. When a nonce contained a prefix not associated with a known backend, the Picker would continuously rebuild, re-resolve DNS, and eventually throw a 500 "Server Error" at RPC timeout. The Picker now promptly returns a 400 "Bad Nonce" error as expected, in response the requesting client should retry their request with a fresh nonce.

Additionally:

• WFE unit tests use derived nonces when "BOULDER_CONFIG_DIR" == "test/config-next".
• Balancer.Build() in "noncebalancer" forces a rebuild until non-zero backends are available. This matches the balancer/roundrobin implementation.
• Nonces with no matching backend increment "jose_errors" with label "type": "JWSInvalidNonce" and "nonce_no_backend_found".
• Nonces of incorrect length are now rejected at the WFE and increment "jose_errors" with label "type": "JWSMalformedNonce" instead of "type": "JWSInvalidNonce".
• Nonces not encoded as base64url are now rejected at the WFE and increment "jose_errors" with label "type": "JWSMalformedNonce" instead of "type": "JWSInvalidNonce".

Fixes #6969
Part of #6974

[jsha]

I was concerned this would cause a lot of spurious badNonce errors during normal rolling restarts of nonce-service, because one WFE would learn about a new nonce-service instance before the others know about it. However, @jcjones mentioned in #6404 (comment):

We've already taken the efforts to ensure smooth roll-off of the boulder-nonce-redeem-grpc and boulder-nonce-generate-grpc services: the generate service is stopped at least 30 seconds before the redeem service stops, so that nonces in flight can be serviced.

So I think we're covered here. Though we should probably find someplace to document this as best practice for deploying Boulder.

[sheurich]

I was concerned this would cause a lot of spurious badNonce errors during normal rolling restarts of nonce-service, because one WFE would learn about a new nonce-service instance before the others know about it. However, @jcjones mentioned in #6404 (comment):

We've already taken the efforts to ensure smooth roll-off of the boulder-nonce-redeem-grpc and boulder-nonce-generate-grpc services: the generate service is stopped at least 30 seconds before the redeem service stops, so that nonces in flight can be serviced.

So I think we're covered here. Though we should probably find someplace to document this as best practice for deploying Boulder.

This sounds like a great approach to minimizing badNonce errors after nonce-service restarts. How does the generate service get stopped ahead of the redeem service?