Allow ACME revocation with a different Account private key

[hslatman]

What would you like to be added

Support for revoking a certificate using ACME with a different Account than was used to request the certificate.

Why this is needed

According to RFC8555, paragraph 7.6, a server MUST consider at least the following accounts authorized for a given certificate:

• the account that issued the certificate.
• an account that holds authorizations for all of the identifiers in the certificate.

In addition to that:

The server MUST also consider a revocation request valid if it issigned with the private key corresponding to the public key in the certificate.

Because of potential memory issues, the second case for accounts hasn't been added in #625 and we don't want users of step-ca to get OOMs. The other two authorization flows are supported in step-ca (after #625 is merged).

This specific flow might be of use in cases where a third party has gotten access to infrastructure that serves the certificate and a new account key is created after regaining control of said infrastructure. This case is also described by Let's Encrypt: https://letsencrypt.org/docs/revoking/#using-a-different-authorized-account. For the step toolchain, specifically, we could add a special emergency ACME flow to revoke certificates without requesting the actual certificate when step-ca supports this authorization flow.

One approach to support this use case is to add (a) new method(s) on the nosql database interface that allow(s) iterating through results, without all of them having to be passed (at once) back to the caller. This could be accomplished by taking a channel or callback function. A potential function signature looks like this:

Iterate(bucket []byte,  cb interface{}) error

This way the caller has control over what happens with the entries in the database, like filtering out items that don't match a specific state. Something similar may be used to update multiple entities at once.

A larger project that might help move this issue forward is support for an SQL (interface to the) database. This has been worked on in #709, but that's far from complete.