Rather than having the `BouncerHTTPRequestHandler` bounce/redirect
requests based on how many have arrived it is more reliable to follow
the way we did this in unit tests and decide based on the request
UA. By setting a distinct UA per VA it's possible to more precisely
define how many requests from each VA should be redirected to the
real key authorization.
Using the count was flaky because occasionally the remote VA
requests would arrive before the primary VA expending the VIP
request quota and bouncing the primary VA validation request. The
`test_http_multiva_threshold_pass` unit test expectation was that
since 2 of the 3 requests would pass that the test would pass but
since the primary VA is treated differently (it must always see a
valid result for the remote VA results to be considered) the test
would fail when the requests were scheduled this way.
Something particular to CI seems to result in the primary VA
being scheduled after the remote VA goroutines more often
than on faster machines/local testing. I had very little
luck reproducing locally but in 10 CI builds of master
with the count-based `BouncerHTTPRequestHandler` tests I saw
`test_http_multiva_threshold_pass` fail 2 builds. After switching to
this branch's UA-based `BouncerHTTPRequestHandler` 10/10 builds passed.
Resolves https://github.com/letsencrypt/boulder/issues/4147
c2ad80f774