Overflow behavior shall be a property of the subscriber port, not the service

## Brief feature description

Currently, the `enable_safe_overflow` behavior is part of the service but it should be actually a subscriber property for its buffer behavior.

Comment from @elBoberido :

I think it is not only a property of the subscriber but also the publisher. If it is only the subscriber one could easily create a denial of service. The publisher also has to opt in for the blocking.

Also the `safe overflow` property shall be renamed. Comments from a past discussion:
* I would go with `QueueMode`/`QueueType`/`QueueBehavior` and `RingBuffer`/`CircularBuffer` and `Fifo`
* My only objection is to "safe". Ideally the name is descriptive of what it actually does. Also keep in mind that the publisher and subscriber have different strategies to handle the same underlying issue -- there is one publisher, but multiple subscribers -- and each subscriber could have a different contract.

No files, tests, or entry points are named. Start by tracing enable_safe_overflow from the service into subscriber and publisher buffer handling, then review the existing queue configuration and related API discussions. Done means the overflow behavior and naming are defined consistently for both publishers and subscribers, with the relevant behavior covered by tests.

Written by the indexing model from the issue text.