Liveliness payload (watchable resource)

[skreborn]

Liveliness tokens can't currently hold data. To work around this at the moment, one needs to declare a Publisher, a PublicationCache, and a LivelinessToken on the same key expression on the sending side, plus two FetchingSubscriber instances (one to receive data and another to monitor liveliness) on the receiving side. This is cumbersome and error prone.

What a liveliness token with a payload would provide is essentially a watchable resource; one that always has a value, which can be changed later, and goes away when the token is dropped. This appears as a use case several times in our projects, and it would be greatly beneficial to include in Zenoh itself to reduce both complexity and resource usage.

@Mallets has previously brought to my attention an issue with this: there needs to be a deterministic system in place to deduplicate liveliness tokens that also doesn't change the excellent performance characteristics of Zenoh. I argue that keeping only the latest payload is a perfectly viable way forward - it should be the developer's responsibility not to publish conflicting data on a single key expression from multiple clients -, but I'm open to alternatives.