dbtemprelease's destructor can fail to restore state and assert on failure

Currently dbtemprelease's destructor attempts to acquire the same lock type as was yielded and restore the thread's client context to its pre yield state. If the lock is a read lock and the context's namespace belongs to a database that was closed during the yield, restoring the context will fail and dbtemprelease's destructor will assert.

Asserting in dbtemprelease's destructor seems particularly unsafe because as a raii class its destructor is designed to be called when another exception is active.

There seems to be a way to detect an active stack unwinding exception in a destructor, but it may be unreliable and there is no way to replace this exception with a higher priority exception about an inability to recover the thread's client context.

Provisionally two options for dealing with this are:

• Implement a dbtemprelease with a destructor that cannot fail to restore state.
• If dbtemprelease can fail to restore state, it should not be implemented as an raii class but perhaps instead using exception forwarding, maybe something like:

  try {

  releaseState();

  doSomething();

  restoreState();

  } catch ( ... ) {

  restoreState(); // may throw

  throw;

  }

See SERVER-5101 for an example of the dbtemprelease destructor assertion.