Aliases pointing within the original search scope could cause
the same entry to be returned multiple times. Check for subtree
scope and duplicate scopes.

Must save/restore mcd cursor if we're doing a scope-based search.

This needs to be streamlined in 2.5, current tool API is a mess.

In server mode, make sure the entry was actually ours

Assigned ITS#, tweaking. This ITS includes
	4f05d992
	716b35e1
	be792fae

Must also reset search cursors

Invoked before a blocked writer waits for socket to be writable.
Use in back-mdb to release reader txn while waiting.

Ondrej Kuznik authored 12 years ago and Howard Chu committed 10 years ago

- bdb deallocates cursor after some tool operations but expects it to be
  around every time it is called
- mdb tries to allocate a second transaction while it already holds one,
  deadlocking
- op->o_hdr must exist for most uses of op, but o_tmpmfuncs need not
- what about indexing after a tool modify? Does it happen automatically?

Better check for missing IDs

mdb_idscopes was remembering the IDs of every entry it checked;
it should only have been saving the IDs of entries that were
actually in the search scope. The extra entries filled the scopes
array, causing a loop searching for a parent entry that was
never inserted.

Partially revert 47f6aec6
Was using RANGE_FIRST/RANGE_LAST on an IDL known to *not* be a range.

DN notfound is authoritative, don't ignore the result

Don't need to reindex all the attr values if there were no deletes.

Otherwise this is a no-op in various NOSYNC/MAPASYNC situations

op.o_extra is only used with threading

Works now, but still 2x slower. Leave disabled.

If multiple ops used the same opinfo the refcount wasn't being decremented