Allow specifying multiple component categories (#187)

It was decided for this again XD

Author: Marenz

RELEASE_NOTES.md

@@ -11,6 +11,7 @@ In this release, we have made some changes to the API to improve the user experi
 * `id` was renamed to `dispatch_id` in all requests.
 * Naming conventions were updated to match API projects.
 * The possibility to update the `dry_run` and `type` fields was removed.
+* The ComponentSelector now can contain multiple component categories.
 
 ## New Features
 

proto/frequenz/api/dispatch/v1/dispatch.proto

@@ -257,27 +257,32 @@ message DispatchFilter {
 }
 
 // Parameter for controlling which components a dispatch applies to
-// either a set of component IDs, or all components belonging to a category.
-//
-// When specifying a set of IDs, all IDs should have the same component
-// category, mixing components from different categories in one dispatch
-// message is not supported.
+// either a set of component IDs, or a set of component categories.
 message ComponentSelector {
   oneof selector {
     // Set of component IDs
     ComponentIDs component_ids = 1;
 
-    // Component category
-    frequenz.api.common.v1.microgrid.components.ComponentCategory component_category = 2;
+    // Component categories
+    ComponentCategories component_category = 2;
   }
 }
 
 // Wrapper for controlling dispatches with a set of component IDs
+// Required as we can't use `repeated` directly in a `oneof`
 message ComponentIDs {
   // Set of component IDs
   repeated uint64 component_ids = 1;
 }
 
+// Wrapper for controlling dispatches with a set of component categories
+// Required as we can't use `repeated` directly in a `oneof`
+message ComponentCategories {
+  // Set of component categories
+  repeated frequenz.api.common.v1.microgrid.components.ComponentCategory component_categories = 1;
+}
+
+
 // Ruleset governing when and how a dispatch should re-occur.
 //
 // Timezone Note: Timestamps are in UTC. It is the responsibility of each microgrid to translate UTC