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
Merge branch '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
Merge branch 'release-2.0.x'
Add a new webhooks framework and port over the review request published hook.

This change adds a new webhooks framework which obsoletes the rbwebhooks
extension. As more and more web services start integrating with each other,
it's becoming more expected that these sorts of facilities will be in the core
product.

The payloads for events piggy-back on the WebAPI's serialization routines. This
means that we get all the relevant data, as well as the links for each
resource. This makes the payload for the webhook much more useful than it was
in the extension.

Additionally, there's an X-ReviewBoard-Event header which lists the event name,
and an X-ReviewBoard-Signature header which is an HMAC signature of the
payload. If the webhook is configured with a 'secret', that secret is used as
the key for the HMAC digest.

This new framework currently implements the `review_request_published` event.
Implementation for the others will come once this is approved.

Testing Done:
Set up a webhook to point to requestb.in and published a review request.
Checked the request bin and saw the expected JSON payload with valid links, as
well as the correct headers.

Reviewed at https://reviews.reviewboard.org/r/6014/