Race condition with ddoc deletion/recreation with same signature

[wohali]

See #548 for the history on this one. Quoting @kocolosk on how our test suite worked prior to #646 landing:

In many cases we have consecutive invocations where the ddocs have the same computed signature. It looks like we're hitting a race condition where we request to delete a ddoc, the server starts closing all the associated indexes, we create a new one with the same sig, the coordinator grabs an Fd from the cache with that sig, and the Fd is closed underneath it during the response.

And to motivate continued work on this:

I think it is possible to observe this bug in normal operations, especially if a user is following the best practice around ddoc upgrades. Deleting the temporary ddoc after migrating the main one could easily kill any in-progress view responses.

Expected Behaviour

Deleting, then recreating a ddoc with the same body (and thus the same computed signature) should not hit a race condition where the newly created ddoc indexes get reaped by the previously invoked ddoc deletion - especially when following the CouchDB best practice around ddoc upgrades in production environments.

Current Behaviour

See the overview above.

Steps to Reproduce (for bugs)

Wind your repository back prior to #646 landing and run the reduce_builtin.js test suite in a loop.
We should write a new test harness for just this bug, should be easy to hit if we do so from within Erlang, for instance.