to make sure that data was create using the same (or compatible) version
of concurrent_hash_map.

Also change order of some members so that embedded_segment (which size is
dependent on size of the mutexes used is at the end). This allows to have
segment_enable_mutex aligned to cacheline.

Copied from pmem/pmdk.

Using uint64_t removes padding.

concurrent_hash_map: remove wrong assert in get_node method

Template locks

Change lock implementation in hashmap to use templates instead of
compile time parameter.

Changes are related to pretty complicated c++ syntax for
template derived class using a member it inherits from its template base class.
Coding convention is:
* To get types defined in base class in derived class
        using name_of_type = typename base_class::name_of_type
* To get access to methods defined in base class
        using base_class:method_name
* To get access to fields defined in base class
        this->field_name

As hash_map_node_base is now template, it's impossible to determine type
of empty_bucket defined in way it was until now - so now it's removed.
IMHO checking if node is nullptr is cleaner than comparing it to
empty_bucket(which is nullptr anyway)

Those functions are redundant, and contain no more needed
compartions pointer to 63. Aplication logic without such calls seems to
be little bit more readable

Condition in the assert is not guaranteed to be true - it was
added by mistake in: 7d7eebac

It's needed to be used by user as template parameter.

 pmem::obj::experimental::internal::shared_mutex_scoped_lock ->
 pmem::obj::experimental::shared_mutex_scoped_lock

This change may be not displayed properly by git.
Try:
git show SHA --anchored="namespace"

Fix string sso usage

Use non_sso_data() and sso_data() methods instead of direct access to
make sure data is accessed only when it is initialized.

In insert, it was wrongly assumed that if size < sso_capacity it means
that sso is used. It is possible that non_sso type is used and
size is < sso_capacity so explicit check is needed.

concurrent_hash_map: reimplement my_mask

Fix release build errors

my_mask is a variable which is reinitialized on each process
restart. Until now, v<> was used for this purpose. Because v<> is not
productized yet, reinitialize my_mask in runtime_initialize() method. Now,
runtime_initialize() MUST be called after proccess restart.

In future, when v<> is productized, we may switch back to using it.

and call it in every test before using hashmap

concurrent_hash_map: implement insert using tx

concurrent_hash_map: add test for concurrent inserts with the same key

Hash map minor refactoring

travis: limit the coverage build

Implement inserts which take rvalue ref uisng internal_insert.
This is more consistent with implementation of other inserts.

This approach simplifies the code and slightly improves performance.

Vector insert fix

and add tests for interators.

Fix a heterogeneous typo

Multithreaded concurrent hashmap API tests

This is the only possible use case for this function. Calling construct
with index other than size() would result in calling constructors
on already initialized memory.

insert_gap() method worked incorrectly. It used std::move_backward to move
elements in a vector, ignoring the fact that memory after size() was uninitialized.

This resulted in operator= being called on uninitialized elements instead of
copy/move constructor.

Fix this issue by reimplementing insert_gap as internal_insert. Use generic
implementation for iterators to implement all cases.

and change name of construct_range_copy to construct.

conctruct_range can be implemented using construct_range_copy by passing
std::make_move_iterator(iterator) as parameters.