Bidirectional provider implementation

[rafaeling]

Introduced the FilterManager structure to manage filter subscriptions based on the lowest time interval.

Added new fields to the Subscriptions struct to manage ChangeSubscription and Providers by their UUID.

Modified sender: broadcast::Sender in ChangeSubscription to sender: broadcast::Sender<Option> to allow receiving None when the sender is gone. This enables returning an error (VISS case) or None to the consumer.

Implemented logic to propagate time-based filters to providers, notify subscriptions according to the time interval, and claim signals by providers during startup.

Added VISS subscription integration tests.

[codecov]

Codecov Report

Attention: Patch coverage is 44.79532% with 472 lines in your changes missing coverage. Please review.

Project coverage is 62.69%. Comparing base (0985941) to head (956e338).
Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
databroker/src/broker.rs	32.20%	221 Missing ⚠️
databroker/src/grpc/kuksa_val_v2/val.rs	35.05%	189 Missing ⚠️
databroker/src/viss/v2/server.rs	0.00%	23 Missing ⚠️
databroker/src/grpc/kuksa_val_v1/val.rs	0.00%	17 Missing ⚠️
databroker/src/grpc/kuksa_val_v2/conversions.rs	20.00%	8 Missing ⚠️
databroker/src/viss/v2/types.rs	0.00%	5 Missing ⚠️
databroker/src/filter/filter_manager.rs	97.61%	4 Missing ⚠️
databroker/src/types.rs	75.00%	3 Missing ⚠️
...tabroker/src/grpc/sdv_databroker_v1/conversions.rs	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #149      +/-   ##
==========================================
- Coverage   63.77%   62.69%   -1.08%     
==========================================
  Files          36       37       +1     
  Lines       17637    18325     +688     
==========================================
+ Hits        11248    11489     +241     
- Misses       6389     6836     +447     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[terbshaeusser-itk]

I also noticed during some testing that no UpdateFilter request is sent to the provider if no timebased filter is given in the VISS subscription message. Is this intentional? How would the provider in this case know, when to send new values?

[rafaeling]

I also noticed during some testing that no UpdateFilter request is sent to the provider if no timebased filter is given in the VISS subscription message. Is this intentional? How would the provider in this case know, when to send new values?

Yes, it is intentional, my interpretation is that TimeBased filter is kind of mandatory -> (Arguments, of which path and filter are mandatory) https://www.w3.org/TR/viss2-core/#subscribe

I cannot find anywhere in the specification what should be the expected behaviour if the TimeBased filter is not provided in the subscribe request https://www.w3.org/TR/viss2-core/#timebased-filter-operation

[lukasmittag]

In general I agree with @rafaeling, it seems not to be stated as clear as we would want:

The client may send a [subscribeRequest](https://www.w3.org/TR/viss2-transport/#dfn-subscriberequest) message to request a subscription to one or more signals, thereby requesting the server to repeatedly return subscription event messages, as specified by the [filter request](https://www.w3.org/TR/viss2-core/#filter-request) described in the [[viss2-core](https://www.w3.org/TR/viss2-transport/#bib-viss2-core)]. The server MAY reduce the number of [subcriptionEvent](https://www.w3.org/TR/viss2-transport/#dfn-subscriptionevent) messages sent to the client in order to reduce processing demands.

You can understand it in two ways:

• repeatedly return subscription event messages -> if no timebased filter is set sent continously at the rate you want
• as specified by the filter request described in the [[viss2-core] -> if timebased filter is set accordingly to it

but since it is in the same sentence it leaves doubts if timebased filter is mandatory.

[terbshaeusser-itk]

You can understand it in two ways:

* repeatedly return subscription event messages -> if no timebased filter is set sent continously at the rate you want
* as specified by the [filter request](https://www.w3.org/TR/viss2-core/#filter-request) described in the [[viss2-core] -> if timebased filter is set accordingly to it

but since it is in the same sentence it leaves doubts if timebased filter is mandatory.

I think there is a misunderstanding here. Our goal was not only to allow the client to basically throttle the sending of values but also to allow subscription based systems as a provider. It should be possible to have a provider that only sends values as long as at least one client is subscribed. This would help to reduce system load and unnecessary computations that might be necessary to transform "raw" signals to VSS signals before they are published to the databroker.

If an UpdateFilterRequest is now only sent when a subscription filter is present, the provider can never be sure if a client (without filter) is subscribed or not. Thus, the provider would need to send values all the time, just like in the current implementation.

[rafaeling]

You can understand it in two ways:

* repeatedly return subscription event messages -> if no timebased filter is set sent continously at the rate you want
* as specified by the [filter request](https://www.w3.org/TR/viss2-core/#filter-request) described in the [[viss2-core] -> if timebased filter is set accordingly to it

but since it is in the same sentence it leaves doubts if timebased filter is mandatory.

I think there is a misunderstanding here. Our goal was not only to allow the client to basically throttle the sending of values but also to allow subscription based systems as a provider. It should be possible to have a provider that only sends values as long as at least one client is subscribed. This would help to reduce system load and unnecessary computations that might be necessary to transform "raw" signals to VSS signals before they are published to the databroker.

If an UpdateFilterRequest is now only sent when a subscription filter is present, the provider can never be sure if a client (without filter) is subscribed or not. Thus, the provider would need to send values all the time, just like in the current implementation.

Fixed: If the subscribe method doesn’t specify a TimeBased filter, the default time_interval value used will now match the value provided when the signal is claimed from the databroker.

[lukasmittag]

LGTM

[lukasmittag]

https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/issues/5893 since it is an eclipse wide issue and all checks beside the one are not failing its good to merge.