Prevent crashes when unable to get/create a ReviewRequestVisit.

Under some unknown race condition, it's possible that looking up or
creating a ReviewRequestVisit will fail when viewing a review request.
This isn't the worst thing in the world, and is likely a temporary
problem (probably due to two requests for creating the same
ReviewRequestVisit at once).

Instead of crashing, we now log the failure and continue on.

Reviewed at https://reviews.reviewboard.org/r/5959/
Merge branch 'release-1.7.x' into release-2.0.x
Allow for age-based filtering when reindexing for search.

This updates our SearchIndex to tell Haystack which field should be
considered to determine the age of a review request, in order to speed
up filtering.

Now, when running update_index with `--age=<hours>`, only review
requests that have been updated in <hours> will be updated or added to
the index.

Reviewed at https://reviews.reviewboard.org/r/5937/
Switch the default SVN backend to PySVN and require a newer Subvertpy.

While Subvertpy is easier to build, it's less complete than PySVN, and
has been the source of several bugs. Some users who have tried switching
to PySVN from Subvertpy have had issues due to a version of Subvertpy
remaining on the system.

We now default to PySVN as the backend if it's installed. It's
better-tested and likely to be more compatible.

For Subvertpy support to work, a minimum version of 0.9.1 must be
installed, since older versions have caused errors we don't want to deal
with.

I also renamed 'imported_dependency' to 'has_svn_backend', which is a
bit more clear and less likely to result in conflicts.

Reviewed at https://reviews.reviewboard.org/r/5957/
Fix the password reset URL.

The regex for extracting the token from the password reset URL was incorrect,
which resulted in an error that claimed "The password reset link was invalid,
either because it expired or has already been used."

Testing done: Went all the way through the password reset flow successfully.

Fixes bug 3395.

Reviewed at https://reviews.reviewboard.org/r/5961/
Fix the reply draft banner sticking around after a second publish.

Publishing a reply to a comment and then following it up with a second
reply would result in the reply banner sticking around, acting as if the
publish hadn't gone through.

This happened because signal handlers for the "publishing" and
"destroyed" events were registered twice on the first ReviewReply, which
would cause the state to mess up. We only really needed to register
these once.

Reviewed at https://reviews.reviewboard.org/r/5964/
Merge branch 'release-2.0.x'