When creating a new review request with a change number on SCMs that

support it (i.e. Perforce), there's the possibility of a race condition.

We do a check to make sure there are no existing review requests with

the given change number, then create the draft and diffset history, and

then finally save the review request. In some cases (for example, the

SCM is being super slow fetching information for the draft), users may

attempt a second time. This second try will then error out with a

database IntegrityError (emailing the admins and returning a 500)

rather than reporting back a useful error via the API.
This change adds some additional bullet-proofing to the creation

process. In the case where the initial check for the changenum succeeds

but the save operation fails, we'll then roll back the created diffset

history and return the ChangeNumberInUseError.

Added test case that triggered the issue. Saw that after the changes to

the manager, the test case succeeds.