Improve the name and documentation of RPC `AddComponentBounds`

[tiyash-basu-frequenz]

What's needed?

This RPC, for a given component and metric,

• receives a vector of bounds from a client,
• adds it to the existing set of bounds,
• intersects all the bounds in the set,
• sets the resulting pair of bounds as a the final bounds of the component's given metric,
• and finally removes the received pair of bounds from the set (after a user-provided duration), recomputes the final bounds again, and updates it in the component.

The verb Add might not accurately represent this action, and could be misleading.

Proposed solution

Perhaps Augment is a better verb?

Also, it looks like the documentation needs to be improved to be more accurate.

Use cases

No response

Alternatives and workarounds

No response

Additional context

No response

[llucax]

Input from ChatGPT:

---

"Augment" is better than "Add" but still may not fully capture the idea of both adding and then later removing or recomputing after a duration. Here are a few alternatives to consider:

1. ApplyBounds: This verb emphasizes that bounds are not just being added; they’re being applied to the metric, intersected, and will later be removed.

2. ImposeBounds: This choice suggests enforcing bounds temporarily, implying that they may change over time.

3. ExtendBounds: "Extend" implies enhancement or adjustment, with potential to reconfigure the bounds as new inputs are applied.

4. EnvelopBounds: "Envelop" could work, suggesting that bounds are temporarily wrapping or containing the metric’s state.

5. OverlayBounds: If the bounds are temporary and layered, "Overlay" reflects that they are supplementary and will be removed after the specified duration.

Each option has a subtly different implication, but ApplyBounds and OverlayBounds seem most aligned with the behavior you described.

[tiyash-basu-frequenz]

Input from ChatGPT:

This does not help TBH. ChatGPT says AUgment is a better choice than these.

[llucax]

True that there was a high level of noise-to-signal in there, but I actually liked Apply, as it feels more temporary than Add, and I don't really understand why Augment is better than Add or Apply. I also agree with what's pointed out there that Augment does "not fully capture the idea of both adding and then later removing or recomputing after a duration". For me Augment is just more cryptic. For me Add and Augment sounds more like it is growing indefinitely than Apply.

So from my side, I don't see Augment as a clear winner compared to Add, and if you also don't see that Apply is a clear winner, I'm more inclined to avoid breaking changes and just leave Add.

[tiyash-basu-frequenz]

I do not see how Apply is a better choice than Augment. Augment suggests that it is extending the bounds, which Apply does not. I also do not see any advantage of Apply over Add.

Let's maybe sleep over it for a day or two. We can close the issue if needed.