Add __all__ to reviewboard.extensions.hooks.

The hooks module has a bunch of its own classes, but also imports some stuff
into its namespace (which is then expected to be exposed to the world). This
change adds __all__ to said module in order to clarify what should be exported
(which also makes pyflakes happier).

Testing done:
- Ran pyflakes
- Ran unit tests

Reviewed at https://reviews.reviewboard.org/r/6389/
Merge branch 'release-2.0.x'
Add some features and UI polish for Webhooks.

Now that we have support for webhooks in Review Board, it's time to make
them completely awesome and flexible, without being annoyingly hard to
use.

Previously, our webhooks were global across repositories and were forced
into pre-built JSON payloads. This is pretty par-for-the-course for
webhook implementations, but a few implementations out there had some
nice features that were worth bringing in.

Now, webhooks can be tied to one or more repositories, can be set to
apply only for events not matching a repository (such as review requests
that are only used for file uploads), or can be set to always fire
regardless of whether there's a repository.

They can be set to output JSON, XML, or form data payloads (in which
case there will be a 'payload=<encoded form data>' sent to the server.

Payloads are also no longer limited to what we generate. Users can
toggle an option for specifying a custom payload, which gives them a
CodeMirror widget they can edit. This supports the Django template
format, allowing the use of template tags, with the original payload
provided as the variable context. Several scary tags (such as include,
load, etc.) are disabled, and RequestContext is not used, keeping this
safe.

The webhook UI has been updated to provide a bit more guidance,
especially with the new options.

There were a few changes under the hood as well. Instead of a
`X-ReviewBoard-Signature`, we now use the more standard
`X-Hub-Signature` (followed by GitHub and others). We also provide a
proper `User-Agent`.

Reviewed at https://reviews.reviewboard.org/r/6391/
Fix some issues with the default webhook signal handlers.

While testing webhooks, I hit a few issues with the current signal
handlers, which this change fixes.

First, there's no guarantee that ReviewRequest.publish will have a user
passed, so we can't rely on the user when we get the signal callback.
This is also true when a review request is reopened. Now, we default to
the review request submitter.

We were providing a 'close_type' field in the payload for the closed
handler of 'S' or 'D', which are internal states. We now pass
'submitted' or 'discarded' instead.

We also now use 'reply' instead of 'review' for reply payloads, to help
differentiate them. This leaves room for us to include a 'review' entry
as well, if we decide to.

Unit tests have been written for all the signal-based webhook
dispatchers to ensure they continue to work.

Reviewed at https://reviews.reviewboard.org/r/6392/
Add an is_enabled_for mechanism for NavigationBarHook.

This adds a way for NavigationBarHooks to be enabled/disabled per-user. This is
done by adding a new, optional is_enabled_for flag to the constructor, which is
a callable that returns either True or False.

Testing done:
- Ran unit tests.
- Used this in an extension.

Reviewed at https://reviews.reviewboard.org/r/6390/
Merge branch 'release-2.0.x'
Add the missing managers.py for the webhooks support.
Fix up password reset template to use modern CSRF protection.

Once upon a time, we rolled our own CSRF protection. This file was somehow
never updated for it, and still had a comment about what we should do when
moving to Django 1.2(!).

Testing done:
Went through complete password reset flow.

Reviewed at https://reviews.reviewboard.org/r/6405/
Merge branch 'release-2.0.x'
Switch to a different version of marked.js that fixes in-word underscores.

marked.js has an infuriating bug that even when "github flavored markdown" is
turned on, it has problems with underscores in the middle of words. Worse, it
didn't handle escaped underscores in the middle of hyperlinks, so even when
they were escaped, it was broken in some cases.

This change pulls in a version of marked.js from an open pull request that
fixes these bugs, which means that we no longer have to escape them.

Testing done:
- Ran unit tests
- Posted some changes with underscores mid-word, saw that the escaping was gone
  and that all text looked correct (with no unexpected em or strong).

Reviewed at https://reviews.reviewboard.org/r/6415/
Merge branch 'release-2.0.x'
Stop creating an unwanted history entry on view diff.

In Firefox changing the url hash by setting window.location.hash creates
a history entry. This behaviour is different from chrome et al so
instead we now use window.location.replace to avoid the extra entry.

Firefox will no longer return to #index_header when hitting the back
button after having clicked view diff.

Testing Done:
Visited the diff viewer using View Diff in both Firefox and Chrome
before and after the fix. Chrome's behaviour is unchanged and Firefox
no longer has the additional unwanted history entry.

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

Conflicts:
	reviewboard/static/rb/js/pages/views/diffViewerPageView.js
Fix parsing of perforce CLNs with multiple sections.

As part of the updates to make code compatible with Python 3, I removed the map
call that was used to do pairwise iteration of the sections in VMware-formatted
changelists, and replaced it with a zip. Unfortunately, map and zip have
different behavior, and this would end up chopping off the last section.

This change replaces it with a much more basic index iteration.

Testing done:
Verified that the iteration method cycled over pairs in the expected fasion.
Sent a patch to VMware for them to verify in production.
Allow specifying ?force-text-type=html to Markdown-capable API resources.

Many of our resources support passing ?force-text-type=plain|markdown to
convert to either plain text or Markdown format. Now, these also support
"html" to render to HTML.

This is the first step to moving entirely to server-side rendering of
Markdown content.

Reviewed at https://reviews.reviewboard.org/r/6406/
Support Markdown in the Submitted/Discarded text fields.

We didn't have any proper support for Markdown text in the
Submitted/Discarded text fields before, due to lack of proper plumbing
in the API and in ReviewRequest.close().

Now it's possible to write Markdown and save it. It will render both in
the banner and in the change description box.

Reviewed at https://reviews.reviewboard.org/r/6409/
Improve close description support in the API.

The review request resource now has a 'close_description' field that
will be set to the close description text, if provided and if closed.
This makes it easier to see the status of a review request without
digging into other resources.

This also deprecates the 'description' field when closing a review
request through the API. The new argument is 'close_description', which
matches the returned value and doesn't conflict with the field.

Reviewed at https://reviews.reviewboard.org/r/6412/
Allow custom arguments to be passed for reply comment requests.

This updates the reply comment resources to allow for unknown arguments
without triggering validation errors. We need this in order to use
fields like force_text_type (for now) and extra_data.

This matches the behavior of other comment resources.

Reviewed at https://reviews.reviewboard.org/r/6418/
Allow force-text-type= to apply to custom fields in extra_data.

Review request and draft API resources now show custom review request
text field values in the requested text type, matching the behavior of
the description, testing_done, etc. fields.

This is done by having MarkdownFieldsMixin own the
serialize_extra_data_field function. It then asks the specific API
resource class to determine if a given field in extra_data supports
Markdown. If so, that field's text will be normalized.

ReviewRequestResource and ReviewRequestDraftResource both provide this
function and check the given field to see if it's Markdown-capable.

Reviewed at https://reviews.reviewboard.org/r/6420/
Support sending force_text_type= in POST requests.

POST requests now support force_text_type=, in order to force the text
to be of a certain type. This mirrors the ?force-text-type= argument in
GET requests.

The resources that support this have been updated to take this argument
in their supported field lists.

The "html" text type is also no longer set as saveable.

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