admin: Replacement tracking for incidents

Problem

In #7298 we added replacement tracking using ARI when a new Order is placed. However, the incident_* tables themselves don't track replacements:

CREATE TABLE `incident_bar` (
    `serial` varchar(255) NOT NULL,
    `registrationID` bigint(20) unsigned NULL,
    `orderID` bigint(20) unsigned NULL,
    `lastNoticeSent` datetime NULL,
    PRIMARY KEY (`serial`),
    KEY `registrationID_idx` (`registrationID`),
    KEY `orderID_idx` (`orderID`)
) CHARSET=utf8mb4;

This data is only found in the replacementOrders table:

CREATE TABLE `replacementOrders` (
  `id` bigint(20) NOT NULL AUTO_INCREMENT,
  `serial` varchar(255) NOT NULL,
  `orderID` bigint(20) NOT NULL,
  `orderExpires` datetime NOT NULL,
  `replaced` boolean DEFAULT false,
  PRIMARY KEY (`id`),
  KEY `serial_idx` (`serial`),
  KEY `orderID_idx` (`orderID`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
 PARTITION BY RANGE(id)
(PARTITION p_start VALUES LESS THAN (MAXVALUE));

Proposal

Add a new admin command that compares a given incident table with the orderReplacements table. I'm not entirely sure of the best form that this should take, but these are some ideas:

• A revocation command which will revoke certificates impacted by a given incident that have already been replaced.
• An information command which will tell the operator what percentage of certificates impacted by a given incident have already been replaced.

Alternative

Modify the schema of the incident tables to include a replaced bool and update this at Finalize time. Obvious downside here is a whole additional query is added to our Finalize workflow.

Start by reviewing issue #7298 and the incident_* and replacementOrders table schemas described here. Clarify whether the admin command should report replacement coverage, revoke affected certificates, or whether the incident schema should change. Done means an agreed design and an implemented, verified way to track or act on incident replacements.