Some yields and priority reductions. Have to slightly rework a few of them later.
message_multiplexer_t::client_t now has a limit on outstanding writes.
Added lazy acquisition mode to semaphore_acq_t
Removed per-multiplexer throttling again. I can't get this to work easily.
Attempt at implementing a per-mailbox limit of outstanding writes.
That also wasn't quite right.
Revert "Attempt at implementing a per-mailbox limit of outstanding writes."

This reverts commit 23a418a8162835d24be435bf5f89cc142f791396.
Merge branch 'next' into daniel_backfill_latency_tweaks
Revert "Removed per-multiplexer throttling again. I can't get this to work easily."

This reverts commit 9ac1802530c3325e893ed8cdb59a03f989987159.
Ok, looks like per-multiplexer client throttling did not work because of two blatant oversights.
Increased multiplexer client outstanding write limit. Seems faster that way.
Ok, actually in release it seems better with a smaller limit.
Revert "Increased multiplexer client outstanding write limit. Seems faster that way."

This reverts commit b3681269cd015c9cafdb0682edc6094797f90711.
Some clean-up and also introduced first improvements for sindex creation.
Attempt at making sindex post construction less of a superblock hugger
Revert "Attempt at making sindex post construction less of a superblock hugger"

This reverts commit 54f813a0726f04092fff884e02fd450d55b77923.
Secondary index post construction optimizations
Merge branch 'daniel_backfill_latency_tweaks' of github.com:rethinkdb/rethinkdb into daniel_backfill_latency_tweaks

Conflicts:
	src/rdb_protocol/btree.cc
Merge branch 'next' into daniel_backfill_latency_tweaks
Make acquire_superblock_for_write actually take separate access codes for the block and the txn. Yet have to verify that the cache eats this correctly.
I felt like having a write transaction which acquires the superblock in rwi_read was a bit risky, given that I'm not 100% sure if it could screw up our cache's snapshotting. Here's a different approach.
Fix to previous commit