Add should_send_email to the user prefs form template.

Part of the change for should_send_email got lost on 1.7.x. This fixes it.
Trivial change.
Fix review counters when deleting or switching close states.

There were some obscure cases where users could trigger negative
counters in the dashboard for review requests. These have been hard to
track down, but with enough bugs opened, we had a somewhat decent
starting point for some of these.

What all the repro cases had in common was that a review request was, at
some point, discarded. In most other cases, a review request was also
permanently deleted.

Through some digging, I found there were a couple cases where you could
trigger these negative counters:

1) Closing a review request twice with two different statuses (through
   the API or by opening a review request in two tabs and closing as
   Submitted in one, Discarded in another).

2) Permanently deleting a closed (discarded or submitted) review
   request.

What these had in common is that they were decrementing counts when not
coming from a PENDING_REVIEW state.

This change tightens the code to only decrement when we were in this
state. It also cleans up a lot of the code by moving all the
incrementing and decrementing logic into reusable functions, so that we
never become inconsistent between them.

Unit tests were added to check these new states. Additional tests were
added for other conditions I could think of (which passed anyway, but it
doesn't hurt to beef up the test suite).

I also was able to simplify and strengthen these tests by moving all the
count assertions into a utility function that would guarantee all
possible values were checked. This helped to improve readability,
maintainability, and consistency between the tests.

This change will be backported to release-1.7.x.

Fixes bug #2268
Reviewed at https://reviews.reviewboard.org/r/5997/
Fix review counters when deleting or switching close states.

There were some obscure cases where users could trigger negative
counters in the dashboard for review requests. These have been hard to
track down, but with enough bugs opened, we had a somewhat decent
starting point for some of these.

What all the repro cases had in common was that a review request was, at
some point, discarded. In most other cases, a review request was also
permanently deleted.

Through some digging, I found there were a couple cases where you could
trigger these negative counters:

1) Closing a review request twice with two different statuses (through
   the API or by opening a review request in two tabs and closing as
   Submitted in one, Discarded in another).

2) Permanently deleting a closed (discarded or submitted) review
   request.

What these had in common is that they were decrementing counts when not
coming from a PENDING_REVIEW state.

This change tightens the code to only decrement when we were in this
state. It also cleans up a lot of the code by moving all the
incrementing and decrementing logic into reusable functions, so that we
never become inconsistent between them.

Unit tests were added to check these new states. Additional tests were
added for other conditions I could think of (which passed anyway, but it
doesn't hurt to beef up the test suite).

I also was able to simplify and strengthen these tests by moving all the
count assertions into a utility function that would guarantee all
possible values were checked. This helped to improve readability,
maintainability, and consistency between the tests.

This change will be backported to release-1.7.x.

Fixes bug #2268
Reviewed at https://reviews.reviewboard.org/r/5997/
Merge branch 'release-1.7.x' into release-2.0.x
Allow Review UIs to decide whether they're usable on a case-by-case basis.

ReviewUI subclaseses can now define a `is_enabled_for()` function, which
returns whether it can be enabled for the given user, review request,
and/or file attachment. This allows, for instance, limiting a review UI
based on extra_data on an object, or based on the given user or
Local Site, or anything else.

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