Avoid data races in DcpProducer::control

During code inspection, found that some fields set as part of DCP control message processing are not updated in a thread-safe way.

For example, we see the consumerName member (used for consumers supporting SyncReplication) is updated without thread synchronisation.

This value is potentially heap allocated, and is always read when an associated ActiveStream is closed in removeAcksFromDM() (could happen from an a front-end or AuxIO thread). If the value is changed again after it has been originally set, this could result in a race where we could do a use-after-free.

This will not happen with the known SyncRepl consumers, as they won't update their name multiple times, but we should fix this occurence and others.