Expose all users in the UserResource for public LocalSites.

The addition of public local sites exposed a bunch of assumptions in the user
linking. By default, the user resource within a local site only contains those
users who are actually members of the site. This causes a bunch of bizarre bugs
in rbtools or other consumers of the API, because the links between objects
(such as the review request submitter) could be 404.

This change makes it so that if a local site is public, all users on the server
are exposed in the site's user resource.

Testing done:
Verified that links no longer 404 using cURL. I intend to add a unit test for
this when porting to 2.0.x (since the API testing framework there is much
improved over 1.7.x's)

Fixes bug 3484

Reviewed at https://reviews.reviewboard.org/r/6110/
Update for the new support page infrastructure.

This updates Review Board to work with the new support infrastructure
being deployed on our servers.

rb-site now asks for a Company name, which can also be provided later on
the General Settings page. This name will show up on the support page
when users visit it. We may also want to use this down the road to help
brand Review Board itself.

rb-site will also ask for permission to collect support data, and
explain what we collect and how it's used. This can be changed later
through a checkbox on the Support Settings page. If allowed, rb-site
will up and maintain the support page on install and upgrade.

Reviewed at https://reviews.reviewboard.org/r/6015/
Point users to Power Pack and support contracts after a site install.

After a user installs a site with 'rb-site install', they're now given
links to Power Pack and to our support contracts page. These are
benefits that we historically haven't done a great job pointing new
users to, so we want them to at least know about them as they're getting
going.

We even make the Power Pack trial process a bit easier by giving users
their install key up-front.

Reviewed at https://reviews.reviewboard.org/r/6020/
Include the Python version in the support tracking data.

The Python version is now sent along with the other support data, in
order to better track issues and see what versions of Python are still
being in use.

Reviewed at https://reviews.reviewboard.org/r/6038/
Fix a script injection attack in diff fragments.

When rendering a diff fragment, the user-specified 'index' value was not
checked for malicious/incorrect content, and was then directly embedded
straight into the page. This allowed an attacker to craft a URL with
custom HTML and pass it to another user (such as through an iframe),
running the custom code in their session.

The fix is simple. We just want to make sure that the index value
specified is a valid integer, and disregard it if not.

This vulnerability was found by Uchida.

Reviewed at https://reviews.reviewboard.org/r/6126/
Add access checks for the original/patched file resources.

The original/patched file resources weren't checking whether the user
had access to the review request. This allowed users to access the
original or patched file content of private review requests, if they
happened to know the relevant database IDs.

This mirrors the changes made to 2.0.x, with the exception that in
1.7.x, there are no draft versions of these resources.

Reviewed at https://reviews.reviewboard.org/r/6127/
Switch all references to reviewboard.org to use https.

This updates all the references to reviewboard.org to use https:// and
not http://. Most of these aren't very important, but some (such as
release.py) are necessary.

Reviewed at https://reviews.reviewboard.org/r/6128/
Release Review Board 1.7.27.
Fix several issues with the original/patched file resources.

The original and patched file resources had some very busted queries
for determining which resource to use for the actual FileDiff lookup.
They were considering all DiffSets in the database, and not the ones
associated with the given review requests or draft.

When fixing this, I decided the best and cleanest way to ensure proper
results would be to split the classes into published and draft
resources. We now have a base class for the original/patched resources,
non-draft versions, and draft versions.

I also realized that no permission checking was taking place. This means
that, if a user knows/guesses the proper database IDs, they can fetch
the original or patched file from a private review request that they
don't have access to. Fixing this was as simple as adding some
permission checks.

Unit tests have been added for all of this.

Reviewed at https://reviews.reviewboard.org/r/6124/
Merge branch 'release-1.7.x' into release-2.0.x
Release Review Board 2.0.4.