Fix usage of timedelta.total_seconds() in condensediffs.

The `total_seconds()` method doesn't exist in Python 2.6, so we can't use it
yet. This change replaces it with the equivalent implementation (and moves us
over to using true division throughout this file as a side effect).

Testing done:
Condensed some diffs.

Reviewed at https://reviews.reviewboard.org/r/6304/
Merge branch 'release-2.0.x'
Allow local_site_reverse to take an actual LocalSite.

local_site_reverse was able to take a LocalSite's name, or a request
object, but if you actually had a LocalSite (or None), you'd have to
write your own conditional to extract the name and pass it.

Now, local_site_reverse can take a LocalSite. This saves a database
query, if one is already available, and simplifies calling code.

Reviewed at https://reviews.reviewboard.org/r/6302/
Fix Local Site and validation issues with post-commit hooks.

The post-commit hook support in hosting services had a few issues that
could lead to unintentionally closing the wrong review requests on
other repositories. They also weren't compatible with Local Sites.

The URL for the hook identified the repository, and the URL also
contained the hosting service ID, but we wouldn't use either to properly
validate the repositories. That meant that if a hook was set up to point
to repository 1 on GitHub, and then had a commit referencing a review
request on repository 2 on Bitbucket, things would break.

We now capture the hosting service ID and pass it, the local site name,
and the repository ID to the function that handles closing review
requests. That function will then use that information to narrow down
the list of repositories being processed, in order to avoid operating on
some other review request. The function has also been rewritten to
minimize the number of SQL queries needed.

Local Sites were broken because nothing bothered to check for them. The
URLs were added to the root urlpatterns, and not to
localsite_urlpatterns. There was some code that did something weird with
trying to get a Local Site from a resolved URL, but that didn't really
do anything. Now everything is wired up to allow for hooks on Local
Sites and to restrict operations to review requests on the Local Site.

There's a few other changes here and there to help consistency and to
minimize code. For instance, we had different error responses for
invalid payloads, and they weren't really correct. We just use HTTP 400
now.

Unit tests were added for the three services that support post-commit
hooks. They test hooks with and without Local Sites, and test invalid
repository IDs, Local Site names, and service IDs.

The unit test for testing service registration was also split up into
several tests, since it was testing several things.

Reviewed at https://reviews.reviewboard.org/r/6303/
Merge branch 'release-2.0.x'
Make the Review Dialog use inlineEditors.

Traditionally, the Review Dialog (created either via the "Review" action or
"Edit Review" in the draft review header) had a text box for the body top and
body bottom headers, and a text box for each comment.

This made a lot more sense when the comments were plain text, and the contents
of the text inputs was the same as what the user would see. One thing that
always bothered me about the addition of markdown formatting for comments was
that it was impossible to truly know what you'd get after a review was
published, since we never showed the comments in rendered form. It also meant
that we were potentially creating a huge number of CodeMirror instances, which
made the Review Dialog pretty slow.

This change replaces all the text boxes with rendered text. This makes it more
or less resemble what the user would see after publishing the review. Headers
and footers can be added via the relevant links (either "Add header", "Add
footer", or "Add text" depending on the number of comments), which works a lot
like "Add comment" in the review replies.

The individual comments and other states (whether an issue is open, ship it)
are now all "instant apply". The dialog therefore no longer has "Save" and
"Cancel" buttons, but just a "Close" button. Changes to each individual comment
can still be cancelled.

Testing done:
- Clicked "Review" without a pending draft review. Saw the ship-it checkbox and
  an open/focused inline editor.
- Checked that checking or unchecking "Ship it" would send a request to the
  server, editing the review.
- Clicked "Review" without a pending draft review. Clicked "Ship it" and
  published. Saw a review with "Ship it".
- Edited draft reviews, changing comment text and issue state.
- Added and removed headers and footers, checking that everything was saved
  correctly, and that when the relevant text was empty/null, that the "Add ..."
  links were shown.
- Installed the severity extension and verified that changes to the severity
  fields were saved when clicking "Close" and "Publish".

Reviewed at https://reviews.reviewboard.org/r/6239/
Add a JavaScript view for showing modal dialogs.

RB.DialogView is a wrapper around $.modalBox() that makes it easy to
construct, show, and hide modal dialogs. It can be instantiated and
bound to an element to show the contents of that element as a dialog, or
it can be subclassed to allow another view to act as a dialog.

Reviewed at https://reviews.reviewboard.org/r/6305/
Add a central function for returning the server URL.

We had a lot of code that attempted to build a server URL by fetching a
Site, SiteConfiguration, doing a URL lookup, and building a string. This
was getting silly, so I've added two central functions for this purpose:
get_server_url() and build_server_url().

get_server_url() returns the URL to the root of the server (or a Local
Site, if one of the identifying arguments are provided).

build_server_url() builds a URL off of the server URL. It's a
convenience around calling `urljoin(get_server_url(), ...)`.

Many call sites have been updated to use these new functions. Many still
remain, as we have templates that are building their own URLs, and some
code that's doing fancier URL building, and I didn't want to risk
breaking them right now.

This also fixes a bug with the e-mail headers. We were always referring
to the root of the site, rather than the Local Site, which made it
harder to filter when working on multiple Local Sites.

Reviewed at https://reviews.reviewboard.org/r/6307/
Fix review dialog js-tests.

I had fixed up some of the relevant tests during my overhaul of the review
dialog, but apparently the last time I ran them was before I removed
_bodyTopEditor and _bodyBottomEditor. This change fixes those tests to use the
new _bodyTopView and _bodyBottomView, and does a little bit of extra cleanup
while I was in there.

Testing done:
Ran js-tests. After this change there are still some failures, but all of the
review dialog tests now pass.

Reviewed at https://reviews.reviewboard.org/r/6308/
Fix bug-id format string in js-tests.

The tests for linkification of bugs was never updated when we merged the new
bug-tracker stuff, and so it was still using '%s' instead of '--bug_id--'. This
change fixes that.

Testing done:
Ran js-tests.

Reviewed at https://reviews.reviewboard.org/r/6309/
Offer helpful RBTools setup instructions in the repository list.

This updates the repository list to have helpful action links for
getting RBTools configured against that repository. When the admin
clicks "RBTools Setup", it will pop up a modal dialog box showing the
setup instructions for that given repository.

To make room for the new column, I've also shortened the label for the
"Show this repository" column in the repository list. Upcoming changes
will add new actions to this list.

Reviewed at https://reviews.reviewboard.org/r/6306/
Only show the drag and drop indicator when the review request is editable.

If a user wasn't logged in, or they didn't own a review request, they would
still see some visual feedback when dragging files over their browser window
inviting them to upload the file. This change fixes that.

Testing Done:
Ran JS tests.

Tried to drag-and-drop a file:
  as the creator of the review request - indicator appears
  while signed in as an admin - indicator appears
  while signed in as a different user (not admin) - indicator does not appear
  while not signed in - indicator does not appear

Bugs closed: 3542

Reviewed at https://reviews.reviewboard.org/r/6312/
Merge branch 'release-2.0.x'
Reject PUT with a changenum on file-only review requests.

When updating a file-only review request (which doesn't have a repository), it
was possible to pass in a changenum field, which would then cause a 500 error
trying to fetch the scmtool. This change makes it so that we return
INVALID_CHANGE_NUMBER if there's no repository (since they're all invalid).

Testing done:
- Ran unit tests.
- Used cURL to reproduce the original bug and saw that I got an error message
  instead of a 500.

Reviewed at https://reviews.reviewboard.org/r/6311/
Merge branch 'release-2.0.x'
Add a field on Repository for storing a UUID for incoming webhooks.

This adds new Repository.hooks_uuid, which is used for matching and
validating incoming webhooks. How this is used is up to the hook
implementation, and can be part of the URL, part of HMAC validation,
or whatever else makes sense.

This field is not exposed in the API. It will instead be used by the
various HostingServices in whichever way makes the most sense for their
implementation, and exposed to the user through an upcoming change that
will allow them to provide hook instructions.

Reviewed at https://reviews.reviewboard.org/r/6310/
Add better validation of incoming webhooks for GitHub.

Incoming GitHub webhook requests for the close-submitted webhooks are
now safe from unintentional requests (for incompatible events) or
malicious payloads (from people guessing the URL and sending payloads to
close various review requests).

We now require that the webhook on GitHub be configured with the Secret
field filled out. It must be set to the value of the repository's
hooks_uuid field. The incoming payload will then be validated for a
signature generated with those payload contents and that secret.

The handler will also filter out non-push events, in case the webhook
was configured to "send everything."

This change (and the upcoming ones for Bitbucket and Google Code) do
break backwards-compatibility for existing hooks, but this is necessary
(and we have labeled this an experimental feature).

An upcoming change will assist users in filling out the webhook field
information, along with the value for the Secret field.

Reviewed at https://reviews.reviewboard.org/r/6313/
Add customized instructions for configuring webhooks for repositories.

HostingService subclasses can now provide a set of instructions for
configuring any incoming webhooks that their repositories support. This
is done by setting `has_repository_hook_instructions = True` on the
subclass and then overriding `get_repository_hook_instructions()`.

Any repositories whose HostingServices support hook instructions will
have a "[Hooks]" link in the repository list page in the admin UI.
Clicking this will pop up a modal dialog with the instructions.

Currently, this is only implemented for GitHub. The GitHub instructions
explain the close-submitted webhook, provide examples, link to the page
for adding a new webhook for that repository, and provide all the fields
to fill in.

The other supported services will come soon.

Reviewed at https://reviews.reviewboard.org/r/6314/
Merge branch 'release-2.0.x'
Add better security, errors, and setup for incoming Bitbucket web hooks.

This change improves many aspects of the incoming Bitbucket web hook
support, to improve security, error responses, and to ease setup of
hooks.

The Bitbucket URL now requires a valid hooks_uuid value, making the URL
practically unguessable. When accessing the URL for the repository, the
value provided in the URL will be matched against that of the repository
that was also referenced in the URL, returning 404 if they don't match.

The error responses have improved when the payload is incorrect. Instead
of just returning an empty HTTP 400, we now return an error string, in
order to help identify what went wrong.

Like GitHub, there's now instructions when setting up a Bitbucket hook.
Bitbucket has a helpful URL for adding a new hook with the hook detailed
pre-filled, which we use in the instructions to make it even easier to
get going.

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