Make the security checklist consider HTTP 403 as a correct response.

Some web server configurations may return HTTP 403 when trying to access
certain filetypes. In this case, we should consider that an acceptable response
when testing whether dangerous files can be executed.

Testing done:
Jury rigged up something to throw a 403 HTTPError for a certain file extension.
Saw that before this change, I could reproduce the bug. After, it claims that
everything passes.

Fixes bug 3368.

Reviewed at https://reviews.reviewboard.org/r/5884/
Make our usage of 'e-mail' consistent.

In most places, we use the string 'e-mail' for user-visible text. There were a
few places where we had 'email'. This cleans them up.

Reviewed at https://reviews.reviewboard.org/r/5887/
Send emails to both users and mailing lists for review groups.

When we initially created review groups, we made the assumption that all groups
would have an associated mailing list. This made a lot of sense when
transitioning from an email based code review system. Shortly after, we made
it so that any review group that didn't have a mailing list would instead send
email directly to all the members. This creates a confusing situation whereby
users are expected to subscribe to mailing lists if they're present but
otherwise get emails.

This change adds an option to review groups to specify whether emails should go
only to the list, or to the list plus every subscriber. The default for this is
to keep the current behavior.

Testing done:
* Tested evolution.
* Verified that with this check-box off, the recipient list for a review
  request assigned to a group with a mailing list contained both the mailing
  list and the group members.

Reviewed at https://reviews.reviewboard.org/r/5828/
Merge branch 'release-2.0.x'
Add better support for added and deleted empty files.

The addition and deletion of 0-length files were not included in the diffs of
review requests. This was especially troublesome when we needed to add or
delete an empty ``__init__.py`` file, for example.

This change adds support for including new and deleted empty files in review
requests for Git, SVN, Mercurial, and Perforce. New empty files will be
displayed with the text "This is an empty file.", and deleted empty files will
be displayed with the text "This empty file was deleted. The content cannot be
displayed." (see the attached screenshots).

Testing Done:
I used rbt post and the "New Review Request" page to create review
requests with different Git diffs, and rbt post for SVN, Mercurial, and
Perforce diffs:
- Diff with 1 new empty file
- Diff with 2 new empty files
- Diff with 1 new empty file, 1 new non-empty file
- Diff with 1 new empty file, 2 modified files
- Diff with 1 deleted empty file
- Diff with 1 deleted empty file, 1 modified file
- Diff with 1 deleted empty file, 1 deleted non-empty file, 1 modified file

After this change, the 3 unit tests that tested parsing a Git diff with a new
empty file failed. (Since a new empty file is now included, the number of files
from parse() has increased by 1.)

After updating the 3 unit tests to reflect this change, all unit tests pass.
The new unit tests also pass.

Bugs closed: 895

Reviewed at https://reviews.reviewboard.org/r/5785/
Add initial support for paginators for Hosting Service requests.

We have functions in HostingService subclasses that need to deal with
paginated data. Right now, they're all handling it in their own ways,
but as we move to wrapping more of these in the web API, it's helpful to
standardize them.

This introduces a set of paginators that can be used and subclassed by
the more specific HostingServices to provide a standardized API for
pagination of data.

APIPaginator is designed to perform API requests and handle pagination
through links returned through the payload or headers in some form.
Subclasses are expected to define how API requests are made and parsed.

ProxyPaginator attaches to another paginator (typically an APIPaginator)
and transforms the results. This allows, for instance, a
HostingServiceClient to return an APIPaginator with raw results, and a
HostingService to wrap it and return structured data derived from those
raw results.

Reviewed at https://reviews.reviewboard.org/r/5885/
Move trophies into the database.

Traditionally, when a trophy was awarded, it was just computed in an ad-hoc
manner every time the review request was displayed. This was fine for a basic
implementation, but made it impossible to do things like list all the trophies
that a user had been awarded, or extend the system with new trophy types.

This change lays the foundation for those features by creating a Trophy model,
an extensible set of trophy types, and the code to migrate old review requests
to this new system.

This is based on Behzad's change at /r/4857/. The only real changes I've made
were to clean up the rendering (through use of format_html and piggybacking
on the djblets_deco box template), include the image dimensions in the trophy
type definition, and make it work with users who don't specify their full name.
I've reproduced all of his original testing as well.

Testing Done:
* All unit tests pass.
* Checked with review requests 1000, 1001, and 3 and trophies were displayed
  correctly (or not at all).
* Also tested with a new database, filled with the fill-database script.
* Tested with review request ID's 1000, 10000, 1001, 2222, and 3. Appropriate
  trophies (or none at all) were awarded. The trophies' existence in the database
  was manually confirmed.

Reviewed at https://reviews.reviewboard.org/r/4857/
Use the new hosting service paginators for get_remote_repositories.

get_remote_repositories is now designed to support pagination, making
use of the new paginator classes. When calling get_remote_repositories,
the caller will get back an APIPaginator subclass that can be used to
paginate through all results.

The function also now takes a starting page for the pagination, and a
requested number of results per page.

This will make it easier to write web API that interfaces with
get_remote_repositories, allowing pagination to occur as expected by
callers.

Right now, only GitHub supports this function, so it's the only one that
is affected.

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