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.
Update the Review Board 1.7 docs database for the latest schema changes.
Fix allowing admins to reopen discarded review requests.

Due to a bad conditional, it wasn't possible for an admin (or user with
the appropriate permissions) to reopen a discarded review request. This
worked for submitted review requests, but not discarded.

The conditional now includes the permission check.

Reviewed at https://reviews.reviewboard.org/r/6144/
Guess a file attachment's content type if application/octet-stream.

If a browser claims a file's content type is application/octet-stream,
get a second opinion by asking `file --mime-type`. This helps with some
browsers or server setups where that useless mimetype is being used,
preventing some files from being reviewable.

Fixes bug #2269
Reviewed at https://reviews.reviewboard.org/r/6016/
Don't trust the browser-provided mimetype if it looks bogus.

A user was reporting that their PDF file uploads were being assigned the
mimetype of "text/text/application/pdf", which is completely bogus. If
splitting on '/' produces anything other than a list of two strings, don't
allow it to proceed.

Testing done: Ran unit tests.

Fixes bug 3427.

Reviewed at https://reviews.reviewboard.org/r/6118/
Make SVN keyword handling case-insensitive.

Our existing handling for SVN keywords only works when the keywords had very
specific casing. This change fixes it to lower-case everything first, and does
a case-insensitive regex substitution.

Testing done:
Tested with several diffs that used svn:keywords with various casing.

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