Add component-level diagnostics to API

fearful-symmetry commented 1 year ago

This PR contains a few changes:

Adds a level field to the ActionRequest message type that tags the action as acting on either a unit or the whole component. This contains three level types, with the first being ALL in order to make sure that older non-compatible clients will behave in the expected way. Right now, only diagnostics care about this field.
Alters the behavior of tryPerformDiagnostics to support the level field; diagnostics that are registered at the client-level become associated with the component level, and diagnostics registered with a unit become associated with the unit level.
Adds the concept of a optional diagnostic via RegisterOptionalDiagnosticHook(). These optional diagnostics are triggered by corresponding tag in the params field of the ActionRequest message.
Adds an exported DiagnosticParams that allows the diagnostic actions to take advantage of the params field in a standardized way.
Adds a CPU profile diagnostic tagged as optional.
Add a number of tests.

Additional things to consider:

I'm sure if it's worth expanding DiagnosticParams in additional ways while we're here; there's easily a few forward-looking field we could add, but right now this was strictly focused on supporting optional CPU profiling.
I made the ActionRequest changes with the goal of making changes both non-breaking and relatively consistent with other parts of the API, but I'm not particularly happy with stuff like If level=component, then the consumer should ignore the unit_id and unit_type fields. My other idea was to break apart the ActionRequest message into different types entirely, perhaps with a different API request for diagnostics, as opposed to the currently strategy of using a single API call for actions and diagnostics. That, however, would be a much larger change.