DCP consumer ignores frequency counts sent by producer

When using the new hifi_lru hash table eviction policy the frequency counter is correctly sent by DCP producer to its respective consumer. However unfortunately the consumer does not pick-up the value, and instead uses the default value (initialFreqCount) of 4.

Currently we do not increase the frequency count on mutations - see MB-27235. So this means with replicas in play - if a document is read frequently (and hence its frequency count gets incremented) and then a mutation occurs (resulting in the document being sent over DCP) the replica will have an incorrectly low frequency count.

This could result in potentially evicting hot (as opposed to cold) items from the replica and hence negatively impacting performance.