Using native delayed delivery for saga timeouts makes them difficult to manage

[boblangley]

Describe the feature.

Is your feature related to a problem? Please describe.

See below

Describe the requested feature

Saga timeouts represent part of the business data and capture critical information to execute certain actions at a certain point in the future.
As business requirements change, timeout data might need to change as well, and it's not easily accessible currently.

Saga timeouts have and are tightly coupled to delayed delivery. In the past, the timeout manager was responsible for delayed delivery and delayed messages were stored in the persistence storage, delayed messages were easier to access and manipulate or migrate. Since the introduction of native delayed delivery, delayed messages are stored in the broker in most transports, making them less visible and less accessible and often read-only to our customers. As the Saga Timeouts feature is still tightly coupled to delayed delivery this causes issues for customers that need to query, reschedule, or cancel/revoke saga timeouts as there is no API to perform such an operation in the platform. Users need to resort to manually modifying data in the message broker or persistence store or extend their own saga state and saga handler code and add code to ignore inflight canceled delayed messages that represent a saga timeout.

Describe alternatives you've considered

None

Additional Context

No response