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/
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/
Fix issues with the new GitHub post-commit hook handler.

The new GitHub post-commit hook handler had some issues in production.
First, when adding the hook, GitHub would try to send a "ping" event,
which we did not support. This resulted in GitHub saying that the hook
wasn't functioning properly (though it wouldn't disable the hook).

Second, and more importantly, the hook signature verification failed.
The X-Hub-Signature header contained the prefix "sha1=", which the
handler wasn't expecting. It now looks for this, erroring out if it
doesn't find it.

Reviewed at https://reviews.reviewboard.org/r/6318/
Populate hosting services on initialization.

Hosting services were only populated when something first made use of
them. This meant that, until that happened, any hosting service URLs
weren't actually registered, and would return a 404.

We now populate when initializing. This incurs a small startup penalty,
but one that would be soon hit anyway, and is necessary for hosting
service URLs to be reliable.

This has been broken since hosting service URLs were introduced in 2.0.

Reviewed at https://reviews.reviewboard.org/r/6319/
Fix the signature generation for GitHub payloads.

GitHub payload signatures are encoded in SHA1, but we were encoding in
MD5. This updates our signature code and tests to encode in SHA1.

Reviewed at https://reviews.reviewboard.org/r/6321/
Fix several review fields on non-Local Sites.

Some of the earlier fixes for user and diff links on Local Sites broke
non-Local Sites. This didn't cause the review request pages to break,
but it did cause the fields to disappear. This fixes them by making use
of the new 'local_site=' parameter on local_site_reverse().

Reviewed at https://reviews.reviewboard.org/r/6320/
Add better security and setup for incoming Google Code web hooks.

The Google Code close-submitted webhook now requires a hooks_uuid value,
which will be validated against the repository, returning a 404 if it
doesn't match.

There's some instructions for configuring the hook now as well, which
will direct the user to the proper page and provide them the URL to
configure.

To make this work, I had to fix a bug in our repository configuration
support, which didn't associate a HostingServiceAccount unless that
account required authorization. It attempted to build the account, but
never saved it. This was a simple fix.

Reviewed at https://reviews.reviewboard.org/r/6316/
Release Review Board 2.0.7.
Fix another SVN unicode problem.

When there's a file-not-found error with unicode paths in SVN, we were trying
to format the encoded string into a unicode string to create the error message.
This caused a UnicodeDecodeError when it tried to coerce it using the 'ascii'
codec. I've changed the `FileNotFoundError.__init__` method to cope with paths
which are bytes as well as paths which are unicode.

Testing done: Ran unit tests.

Fixes bug 3425.

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