MB-12110 Extract snapshot marker type correctly

Snapshot type is determined by extracting the corresponding bits
in the marker type bit fields from snapshot marker upr message.

The current implementation checked for equality of snapshot marker
type field with on-disk or in-memory marker type. But, EP-Engine
may send snapshot marker with other bits set as well. In that case
snapshot marker is ignored and snapshot boundaries are missed out
by the updater. Since the snapshot merger fails to detect the
snapshot boundary, multiple entries for a document ends up in
the updater pipeline and duplicates are added into the index.

Change-Id: Ic58df6ec438dc3b2791fe4225a95748737c781e2
Reviewed-on: http://review.couchbase.org/41167
Reviewed-by: Sarath Lakshman <sarath@couchbase.com>
Reviewed-by: Volker Mische <volker.mische@gmail.com>
Reviewed-by: Sriram Melkote <siri@couchbase.com>
Reviewed-by: Michael Wiederhold <mike@couchbase.com>
Reviewed-by: Nimish Gupta <nimish@couchbase.com>
Tested-by: buildbot <build@couchbase.com>
MB-11917 Async map_doc implementation

map_doc function make use of NIF which in turn calls v8 library
to perform map function. Currently this is implemented in
synchronous fashion. Since map may take long amount of time
depending on map function, number of views and number of documents,
it is better to implement it in asynchronous fashion. In order to
implement async map, a template task queue class is implemented and
all map requests are enqueued and the function returns immediately.
4 global threads are created since view engine support 4 concurrent
view indexing. All incoming map requests are randomly assigned to
one of these 4 threads to balance load. These worker threads
dequeue tasks, does the map and sends map results or error as
messages to erlang world. This will help erlang scheduler to get
proper reduction counts for map request and thus perform fair
task scheduling.

Change-Id: I8e53a85fe4056df480e0f74c0cf94c0410ea56c9
Use round-robin scheduling for mapreduce nif workers

Using random work allocation to mapreduce nif worker threads may
cause contention on worker threads and work distribution may not be
uniform. Considering the workload, when a map context is created
the updater uses that context to perform a number of map operations
during the lifetime of the updater. Hence, the best work distribution
may be to assign one worker thread to a map context and use the
same worker for all map tasks for that context. The worker thread
can be assigned in round-robin fashion to each map context created
by the updater.

Change-Id: I70d4c186086c42ad4f06e00a243a08e8757bd94e
Add do_map hook

Change-Id: I049d3efad0135b1c941ee78ecc0283047d5fe373
make n1ql mapper work

Change-Id: I5fa31cee78f0245e61ae381df8d102b45a4bdf52
fix false where clause keys getting indexed

Change-Id: Iad5caaf4a28266fc434e818238063def7ab8d9bf
Merge branch 'hackathon' into toys