Feature request: db and datapoint throttling

[tfa2si]

We'd like to propose adding two complementary throttling features to improve safety, security, and resource efficiency in time‑critical vehicle systems:

1. Global DB throttling (--db-throttle-ms)

   Purpose: Enforce a minimum interval between any consecutive write operations to the database.

   Behavior:

    Introduce a new launch option --db-throttle-ms <N>.
   
    When enabled, the broker will delay or reject any write request that occurs less than N ms after the previous one.
    Disabled with 0
   

   Default: --db-throttle-ms defaults to 10 ms, to provide sensible behavior out-of-the-box while still configurable.

2. Per‑datapoint throttling parameter in VSS metadata

   Purpose: Allow different VSS signals to have individualized update frequency limits.

   Enhancement: Extend VSS metadata schema to include an optional throttle_ms parameter on datapoint definitions.

   Behavior:

   When present, this value overrides the global throttle for writes to that specific datapoint.
   
   If omitted, falls back to the global --db-throttle-ms value.
   

Benefits

Safety: Prevents excessive control-actuator updates that could cause oscillation or electronic noise.

Security: Throttles attackers/bad actors attempting to flood the broker with high-frequency writes.

Performance: Enforces predictable system load and avoids write queue congestion.

Flexibility: Per-datapoint control ensures critical/throttled signals can be handled separately from less-sensitive ones.

[SebastianSchildt]

Thank you for the suggestion.

Note that throttling in databroker will not reduce databroker load by much (still need to parse requests), but rather protect databroker clients.

There has been some discussion in the past here eclipse-archived/kuksa.val#488 and there is some initial support for ProviderStreams and subscribe requests in the API here #141

I do think however it is not fully implemented yet, maybe @rafaeling can give a summary what is currently already possible. (e.g. I am unsure how much we intend the provider to "care" for this to work and how much db is "filtering" itself. Also unsure it applies to actuation streams at all)

[doosuu]

I agree it is more of a provider thing. In the end it is really vehicle network dependant what actually needs to be throttled / de-bounced. We want to stop processing and reduce load in the beginning of the processing chain.

[tfa2si]

Sure there is a provider throttling, but in regards to vehicle network some slower subscribers also would like to have throttling.

[doosuu]

Isn't this more of a per-client configuration then? Can this be achieved via the filter field of the val::v2::SubscribeRequest message?