reduce lock's range in DeleteObsoleteFiles

[ivanabc]

lock spend too much time in DeleteObsoleteFiles

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

[ivanabc]

I signed it!

[googlebot]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for the commit author(s). If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.

[googlebot]

CLAs look good, thanks!

[cmumford]

@googlebot rescan

[cmumford]

@ivanabc can you please rebase this PR on master to make it more current? No problem with your CL, just an issue with our sync tool's ability to deal with old branches.

[npatod]

I have some question regarding this pull request.
1)use case of mutex_.AssertHeld() (called at the beginning of function DBImpl::DeleteObsoleteFiles() )
I think It might be used to allow only one thread to delete a file.
2)if we do not want any synchronisation in this function then no need to call unlock at the beginning of function and again calling lock at the end of function.ideally if we don't required any synchronisation then no need to acquire lock for this function call (before we calling this function)