Depending on the resolution of DM-16503, the MetricTask API may need to change (e.g., getInputDatasetTypes -> getInputDatasetTypesGen2). However, at the time this issue is completed, there should be few enough MetricTask subclasses that the extra work is manageable.
I realized later that there's a simpler, and much more robust way to structure the code that eliminates the need for an everything-at-once conversion – have two MetricTask interfaces, one that's always Gen 2 and one that's always Gen 3. I've edited DMTN-098 accordingly.

(Naturally, only the Gen 2 interface will be implemented now)

The final scope of this ticket will be:

• The full Gen 2 MetricTask interface will be implemented and tested.
• Only timing metrics will be implemented.
• The Configs for the timing metrics will be as simple as possible, with no attention paid to minimizing future code duplication or making the Gen 3 transition easier.
• MetricsControllerTask will have a hard-coded list of timing metrics, with no support for registering additional metrics.
• MetricTask and MetricsControllerTask will have hard-coded equivalents for the metadata requested in DM-11321 and DM-16333.

These limitations will be lifted by later work, linked as blocked by this ticket.

Hi Jonathan Sick and Christopher Waters, would you be willing to review this ticket? Since you have complementary perspectives (verify vs. Gen 3 middleware), I'd appreciate it if you could both look over the changes to all three packages (verify, ap_verify, and dmtn-098).

Given the ticket scope, I don't think I have any major concerns for this with respect to Gen2.  I'm not sure how difficult the conversion to Gen3 will be, but I've made a quick note where I have the largest concern about future trouble.  You're likely already aware of this, but I wanted to raise the point.

This looks good, thanks.