Improve ComponentMetricsRequest documentation

[llucax]

No description provided.

[shsms]

This doesn't feel like it is from the perspective of the ComponentMetricRequest type.

I came up with, the following, might need shortening/cleanup:

      Along with specifying the component ID and the metric that needs
      to be streamed, `ComponentMetricRequest`s are also used to
      determine the channel used to stream the data.

      Data for all requests with the same namespace, component_id and
      metric_id will be streamed through the same channel.  Normally,
      the actors sending the data would make sure the data is not
      duplicated.

      But when multiple unique channels are required, for example, to
      differentiate between raw and resampled data, the requests can
      specify different `namespace`s in the requests.

[llucax]

I ran my text, expanded to include yours, through o1-preview and iterated a couple of times to include all the details I found important. Here is the result

A request to start streaming a component's metric.

Requesters use this class to specify which component's metric they want to subscribe to,
including the component ID, metric ID, and an optional start time. The `namespace` is
defined by the requester and influences the construction of the channel name via the
`get_channel_name()` method.

The `namespace` allows differentiation of data streams for the same component and metric.
For example, requesters can use different `namespace` values to subscribe to raw or resampled
data streams separately. This ensures that each requester receives the appropriate type of
data without interference. Requests with the same `namespace`, `component_id`, and
`metric_id` will use the same channel, preventing unnecessary duplication of data streams.

The channel name must be shared between the requester and provider because both need to
independently retrieve the same channel from the `ChannelRegistry`. By specifying the
`namespace`, requesters determine the channel name, ensuring they can access the correct
channel after subscribing.

What do you think?

[shsms]

This feels misleading because it presents part of the story as the whole story: "By specifying the namespace, requesters determine the channel name".

I would rephrase the last paragraph as follows:

The requester and provider must use the same channel name so that they can independently retrieve the same channel from the ChannelRegistry. This is achieved by using the get_channel_name method to generate the name on both sides based on parameters set by the requesters.

[llucax]

I think that's missing that namespace is key for that unique channel name negotiation. Without it, you can't get a unique channel name for the same metric and component. I'm confused because it is exactly the part you want to remove, but I think it is key to understanding why namespace is there.

[shsms]

The first two paragraphs already explain it very clearly. The third paragraph only has a misleading mention of namespace. I think it makes more sense to focus on the other aspect of how the matching names are achieved on both sides instead.

[llucax]

OK, for me it wasn't that clear, but reading it again, I guess it is, I will update with your last paragraph proposal.

[llucax]

Updated.

[llucax]

Rebased.