FMA subsystem loading unbounded ereports

[smklein]

Corresponds with https://github.com/oxidecomputer/customer-support/issues/1046

Short version: the FMA subsystem does not know how to process any ereports currently, so it does not mark them as seen. However, they are loaded as a part of the input phase, regardless.

To mitigate: We need to prevent the loading of "ereports which the sitrep planner cannot parse" until it's actually able to handle them.

Paths forward:

• Disable the sitrep planner altogether (quickest fix, but doesn't mitigate the other "unknown ereport categories" when we turn it back on).
• Filter ereports by "known-to-planner". This seems slightly more complex, but seems more viable as a mechanism of "only loading what we're going to use, from a set that we will continually reduce".

[hawkw]

Disable the sitrep planner altogether (quickest fix, but doesn't mitigate the other "unknown ereport categories" when we turn it back on).

We should definitely do this for now to avoid the problem in the short term.

Filter ereports by "known-to-planner". This seems slightly more complex, but seems more viable as a mechanism of "only loading what we're going to use, from a set that we will continually reduce".

Once we have a framework for representing diagnosis engines to the main analysis system (i.e. maybe a trait or something?), i imagine we could have each DE expose a list of ereport classes that it cares about or something like that...

[AlejandroME]

Landed in #10360