Support metrics from multiple component connections in the aggregation RPC

[stefan-brus-frequenz]

What's needed?

To support specifying different connections for component metrics in the aggregation formulas, we'll need to extend the syntax to allow an optional source specification after the component ID.

Proposed solution

Example Formula:

(#4[source1] + #5[source2])

Proposed Additions:

 message AggregationConfig {
   // ID of the microgrid for which the formula is being specified.
   uint64 microgrid_id = 1;

   // The metric that is to be aggregated using the specified formula.
   //
   // !!! caution "Metric Compatibility"
   //     Ensure the chosen metric is supported by all relevant microgrid components.
   //     Failure to meet these conditions might result in an aggregation error.
   frequenz.api.common.v1.metrics.Metric metric = 2;

   // The formula used for aggregating the component metric for this microgrid.
   // 
   // ...
+  //     Specifying Sources for Component Metrics:
+  //
+  //     - Syntax:
+  //
+  //       `#ComponentID[connection_name]`
+  //
+  //     - Components:
+  //       - `ComponentID`: The ID of the component (e.g., `#4`)
+  //       - `connection_name`: The name of the connection (e.g., `dc_connection_1`), enclosed in square brackets `[]`
+  //
+  //     - Examples:
+  //
+  //       - `#4[dc_string_1]`: Refers to the metric from component `4` with connection `dc_string_1`
+  //       - `#4[dc_string_2]`: Refers to the metric from component `4` with connection `dc_string_2`
+  //
+  //     - Notes:
+  //       - Specifying a connection is optional. If omitted, the default connection is used.
// ...
   string aggregation_formula = 3;
 }

Use cases

One might have an inverter with multiple DC strings (connections), and you want to aggregate metrics from specific strings.

Alternatives and workarounds

Alternative Syntax Options

a. Using the @ Symbol

Syntax: #ComponentID@source_name (e.g., #4@source1)

Pros:
Unambiguous: The @ symbol is less commonly used in mathematical expressions, reducing the risk of parsing conflicts.
Clear Association: Clearly associates the source with the component ID.

Cons:
User Familiarity: Users might be less accustomed to this notation, but it's often used in email addresses and annotations, so it's not entirely unfamiliar.

b. Using a Dot .

Syntax: #ComponentID.source_name (e.g., #4.source1)

Pros:
Familiarity: Dots are commonly used for object property access in many programming languages.

Cons:
Parsing Issues: Dots are also used in floating-point numbers (e.g., 3.14), which might complicate parsing.
Potential Ambiguity: Could be confused with decimal points in numbers.

c. Using a Colon :

Syntax: #ComponentID:source_name (e.g., #4:source1)

Pros:
Distinct Separator: Colons are clear separators and not commonly used in mathematical expressions.

Cons:
Potential Conflicts: If the expression language uses colons for other purposes (e.g., ternary operators), this could cause issues.

Additional context

This is pending the following issue.