TCP connections could be more efficient.

[griffinmilsap]

Given the following scenario:

• A publisher to topic on machine A
• >1 subscriber to topic on machine B, all in same process

Currently, all subscribers will receive the TCP transmission and each overwrite the cache with the same (identical) received message that was serialized, sent, received, deserialized and copied multiple times needlessly. Fixing this would involve giving MessageCache a socket/server that it could synchronize with other MessageCaches running
on other machines/processes. This greatly complicates and fundamentally changes the backend message passing design, and may actually degrade performance for SHM and local caching significantly.

WORKAROUND/DESIGN TIP:
This performance issue can be worked around by creating a re-publisher that receives TCP messages once, then re-publishes them into local process/cache such that other subscribers in this process have direct cache access to the
message that was serialized only once from the source process.

[griffinmilsap]

This bug was mostly addressed (for multiple topics in the same unit) by v3.1.2 with message caching. This issue might be fully-addressed by adding Collection Stream republishers as discussed in #11

[griffinmilsap]

Individual writes of message components severely degrade performance, and .. it looks like ezmsg is re-serializing the same message once for each TCP client. Fixes for this behavior are being implemented in the fix/write-optim branch.

[griffinmilsap]

Addressed by #198