Revocation registry management is complicated, and should be automated as much as possible.

We are currently reliant on automated handlers succeeding. If something goes wrong, or if the agent is abruptly terminated in the middle of an operation, then it's possible for a cred def to silently become unusable.

Example:

• a revocation registry is now full, and AnonCredsRevocation.handle_full_registry gets called.
• a new backup registry should be created, but imagine it fails or gets interrupted.
• the end-user does not find out about this, until eventually when they cannot issue credentials.
  Alternative example: the initial handling of the "cred def finished" event fails, and the initial registries don't get created to begin with.
  Ideally, the issuer should not need to worry about, or know how to manually recover from broken states such as this. The agent should ideally be robust enough to manage the lifecycle of revocation registries successfully.

Proposal:

• implement an event-driven design (based on DB transactions) that tracks the different events/operations that are required.
• If an operation completes successfully, it is cleared from the DB.
• If an operation fails, the event can be retried (up to some maximum number). If maximum retries are exceeded, then notify the issuer.
• If the agent gets terminated during an operation, events can be read from the DB on startup, and re-emitted for automated handlers to pick up
  Overall, this will make revocation registry management more reliable and resilient.