Simplify some logic when opening an access baton, and fix a potential bug.
Simplify some logic when opening an access baton, and fix a potential bug.

The old code would close the baton (aka "lock") that it was working on, if
a problem occurred when opening a child (or a cancellation). The close
operation is recursive, so it *could* close a "third party" baton (which
may have been the cause of the error, btw). Rather than closing the
in-progress lock, we now just return an error. The "rollback list" will
close all batons that were opened as part of this operation, and it does
so in a non-recursive fashion.

Note: the above situation is theoretical since all client code must be
aware of its opened/locked batons, and will never overlap them like this.
But if it *does*, then we don't want to close something this operation did
not open. Simply bailing out and relying on the rollback Works.

* subversion/libsvn_wc/lock.c:
  (do_open): simplify the error exits -- don't bother to close the lock
    being opened. The caller's rollback handling will deal with that. Also
    provide a shorter-life pool (iterpool) to a function for its scratch.

jmckaskill/subversion,jmckaskill/subversion,jmckaskill/subversion,jmckaskill/subversion,jmckaskill/subversion,jmckaskill/subversion,jmckaskill/subversion,jmckaskill/subversion