Optimise memberlist kv store access by storing data unencoded.

[stevesg]

What this PR does:
The following profile data was taken from running 50 idle ingesters with
memberlist, with almost everything at default values (5s heartbeats):

52.16% mergeBytesValueForKey
+- 52.16% mergeValueForKey
   +- 47.84% computeNewValue
      +- 27.24% codec Proto Decode
      +- 26.25% mergeWithTime

It is apparent from the this that a lot of time is spent on the memberlist
receive path, as might be expected, specifically, the merging of the update
into the current state. The cost however is not in decoding the incoming
states (occurs in mergeBytesValueForKey before mergeValueForKey), but
in fact decoding current state of the value in the store (as it is stored
encoded). The ring state was measured at 123K (50 ingesters), so it makes
sense that decoding could be costly.

This can be avoided by storing the value in it's decoded Mergeable form.
When doing this, care has to be taken to deep copy the value when
accessed, as it is modified in place before being updated in the store,
and accessed outside the store mutex.

Note a side effect of this change is that is no longer straightforward
to expose the memberlist_kv_store_value_bytes metric, as this reported
the size of the encoded data, therefore it has been removed.

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[pracucci]

Good job! I double checked the usage of KV.store map and LGTM (with regards to the value copy). I would suggest you to also provide a benchmark to see the actual performance improvement. Thanks!

[pracucci]

Manual tests results showed improved performances after this change, so let's get it merged. We can further re-iterate on follow up PRs.