Our design uses separate EventIDs for each attribute. Currently we see
~3500 total subscribes, followed by ~3500 acknowledgements, transmitted
one-per-frame. The entire sequence does not finish within a two second SD
interval leading to timeouts, retries, and poor performance.

All SD messages have the same identifier, so this logic forced the train
must_depart ~3500 times carrying a single message. Very inefficient.

This change improves performance by allowing multiple passengers with the
same identifier aboard the same train; resulting in fewer, larger frames on
the wire.

Upstream logic overrides retention and debounce to zero for SD messages,
forcing any train containing SD passengers to depart immediately.

Use configured times, allowing a train to aggregate multiple SD passengers.

Debouncing would make sense if it was applied on a message-by-message basis
so each gets transmitted "no more often than Xms" dropping all updates
except the final one. However upstream code applies this parameter to decide
when an entire multi-passenger train should depart.

Remove this logic; we're not using the feature, it doesn't work the way we
expect, and it prevents aggregating multiple passengers into trains.

on_message_received supports multiple messages in a single UDP frame
but only processes the message:

- if the message is not SOMEIP-SD
- else if the message is SOMEIP-SD and there’s no subsequent message

After changing the train logic to aggregate multiple SOMEIP-SD messages into
a single UDP frame we want it to process everything found within the frame
no matter if it’s SOMEIP or SOMEIP-SD.