Add test for re-signed OCSP revocation reasons

[aarongable]

In https://bugzilla.mozilla.org/show_bug.cgi?id=1648840, it was seen
that Let's Encrypt's OCSP responder was generating OCSP responses with
an empty revocationReason field, but only for responses which had been
re-signed (i.e. it was correctly providing a revocationReason for the
first few days after a revocation).

This test issues and then revokes a cert, then jumps 20 days forward
to force the ocsp-updater to re-sign the ocsp response. It then checks
that the new response still has the correct revocation reason.

Fixes #4907

[jsha]

This is a nice, clean test improvement! In particular, good insight that we could use the existing twenty_days_ago phase. For some reason I had gotten fixated on the idea that we needed another, "future" phase.

This test just checks that the certStatus is "revoked"; it doesn't check the revocation reason. That's a valuable improvement and I'd be willing to merge this on its own with a tweak to the description and the intent to follow up with a change to also test revocation reason. But it's probably more straightforward to incorporate the reason testing into this PR. Note that the numeric arg to client.revoke(..., 0) is the reason code. To read the reason code we probably just want to look for strings in the OpenSSL output as we do elsewhere.

Also I think we should be getting a copy of the OCSP response body in twenty_days_ago_setup and looping in the "present" until we see different bytes. Otherwise, the test could pass on the strength of the CA's initial GenerateOCSP as part of revocation, without ever hitting the re-signing path.