MB-37233: Fix undefined-behaviour in HashTableBench::createItems
MB-37233: Fix undefined-behaviour in HashTableBench::createItems

Multiple benchs in HashTableBench suffer sporadic failures on cv-perf.
Eg, http://cv.jenkins.couchbase.com/job/kv-engine-cv-perf/14624:

HashTableBench/Insert/iterations:100000/threads:16              939 ns       6273 ns    1600000   155.673k items/s
/home/couchbase/jenkins/workspace/kv-engine-cv-perf/kv_engine/engines/ep/benchmarks/hash_table_bench.cc:94: Failure
 Value of: ht.set(item)
   Actual: 2-byte object <03-00>
 Expected: MutationStatus::WasClean
 Which is: 2-byte object <02-00>
 Expected WasClean for item:Item[0x7f44473fd770] with key:cid:0x0:Thread7::17�D
   value:Blob[0x7f448d9a13f0] with size:1 age:0 data: <x>
   metadata:ItemMetaData[0x7f44473fd778] with cas:0 revSeqno:1 flags:0 exptime:0
   bySeqno:-1 queuedTime:0 vb:0 op:mutation nru:2 datatype:0 deleted:false

The cause of the failure is that:
  - in HashTableBench::createItems we expect to create unique items (ie,
    no duplicates for <key>), so we always expect WasClean at HT::set()
  - for every item, we make a DocKey from a fmt::memory_buffer by the
    DocKey c-string ctor
  - but, fmt::memory_buffer is not null-terminated

In the DocKey c-string ctor we copy the memory_buffer by using the
std::strlen function, which is undefined-behaviour for
non-null-terminated buffers.
That sporadically leads to memory corruption which results in getting
<key> duplicates in the vector from HashTableBench::createItems. So, the
result of HT::set() may be different than WasClean.

Change-Id: Ifd80556c89288fe120bc1ba07d28eda79bbed746
Reviewed-on: http://review.couchbase.org/119490
Reviewed-by: Jim Walker <1cd02e31b43620d7c664e038ca42a060d61727b9@couchbase.com>
Tested-by: Build Bot <80754af91bfb6d1073585b046fe0a474ce868509@couchbase.com>

daverigby/kv_engine,daverigby/kv_engine,daverigby/kv_engine,daverigby/kv_engine