Fix Gossip excessive memory consumption by SeenCache

[Nashatyrev]

The SeenCache aims to effectively filter duplicate messages for a longer period (2 minutes by default) than mCache stores (5 seconds by default). The SeenCache implementations shouldn't retain references to received messages' content since it could be significant memory consumption in case of heavy gossip traffic:

The secondary purpose of the SeenCache is to cache messageId (which calculation could be resource consuming) of seen messages based of a fast message id (see SeenCache.getSeenMessageCached() method and FastIdSeenCache implementation)

To address the memory issue the SeenCache implementations should rely on message ids (either slow or fast or both) and don't keep the PubsubMessage references.

To preserve the secondary purpose the FastIdSeenCache.getSeenMessageCached() wraps the PubsubMessage with a wrapper instance which is supplied with the cached messageId when available.

Unfortunately there are no reliable means to create unit tests for memory leak/excessive usage cases

[Nashatyrev]

Basically the concept of messageId encapsulation to PubsubMessage should be revisited and probably refactored. Its current implementation is really confusing
I would remove the notion of messageId from the PubsubMessage as it basically should not be exposed to the client code.
The client code should just be able to supply the function of deriving messageId from a PubsubMessage instance during Gossip construction

[StefanBratanov]

LGTM

[rolfyone]

LGTM