Fix a typo, preventing emails from setting internal encryption header

X-RT-Incoming-Encryption, along with a number of other headers, is
removed from all parts of incoming emails because they are used to
annotate GPG-related properties of the message.  Fix a typo, which
allowed the properly-spelled header to pass through under specific
circumstances.
Remove internal signing and encryption hints from incoming mail

RT uses the existance of the X-RT-Sign and X-RT-Encrypt headers to
decide if the outgoing mails it sends as a result of the transaction
should be signed and/or encrypted.  It standardly inserts these headers
based on checkboxes visable in the web UI; however, it fails to remove
them from incoming mails, allowing external users to create nearly
arbitrary messages signed by the queue's key.
Restrict users to only signing with queue or their own personal keys

While the UI only presents two options for signing, the underlying form
accepted any key ID or email address, and dutifully signed the mail with
the appropriate secret key.  Restrict the accepted values of SignUsing
to the two values that we displayed.
Don't propose any secret keys to users with no email address

GetKeysForSigning, when called with 'force', returns all keys if no
email address is provided.  This caused users with no email address to
have all secret keys offered to them.  Remove the 'force' to ensure that
empty email address are shown an empty list.
Explicitly restrict private keys to ones offered
Avoid spurious update and warning messages on key update

This avoids an ominous-looking warning about failure to remove the key,
when no key was previously set but no key was newly selected.
Require AdminUser to set PGP private key IDs, not merely ModifySelf

Be explicit that modification of the PrivateKey pseudo-column requires
admin rights -- namely, AdminUser, not just ModifySelf.  While the page
that controlls that property is in /Admin/Users/GnuPG.html, accessing
that page requires only the ShowConfigTab right, and modifying the
property on yourself required only ModifySelf.  Combined with the
ability (also granted by ModifySelf) for users to change their own email
addresses, this opened the possibility for users to claim arbitrary
private keys as their own, for use in signing.
Ensure that no --arguments can be snuck to GPG commands as arguments

GnuPG::Interface 0.46 adds code to prefix command_args with a "--" if it
doesn't have one already.  Rather than bump the dependency, explicitly
add the "--" in the two places that we pass in command_args.
Refactor shared code controlling if a message will be encrypted or signed
Refactor RT::Action::SendEmail->Commit to consolidate RecordOutgoingEmail path

Instead of interweaving the logic around the case where
RecordOutgoingEmail is disabled, resolve that simple case first.
When creating tickets via the UI, always set signing/encryption headers
Differentiate "always sign" from "default to signing when composing"

Signing incorporates two related but distinct concepts: first,
verification that the message was transmitted without corruption
(integrity), and second, proof that the message was indeed sent by the
sender (authentication).

When the "Sign by default" queue option is disabled, the only messages
which are signed are those triggered by an action where the sender has
explicitly checked the "Sign" option.  Consequently, messages which are
not generated via the web UI, such as auto-replies, or requestors'
messages which are forwarded to owners, are not signed.  In this
configuration, the signing conveys authenticity, but does not provide
integrity for all messages..

When the "Sign by default" queue option is enabled, all messages default
to being signed, even ones generated automatically.  Thus, emails from
the requestor (which may have arbitrary content!) will be signed by the
queue's key when redistributed to owners and AdminCcs.  In this
configuration, the signing ensures integrity, but (because signing
happens automatically) means that no authenticity should be attached to
messages thus signed.

Because the simple configuration option fundamentally changed the
meaning of the signature, exchanging integrity for authenticity, with no
warning, alter it to instead provide an additional option ("Sign
auto-generated messages") which takes the burden of this change in
meaning.  Degrade the "Sign by default" option to describing the default
state of the checkbox on the ticket create or reply page.
Blacklist components from automatic, argument-based CSRF whitelisting

Not all pages which take only an id query parameter are idempotent.  The
ticket bookmark toggle — generally used via ajax — requires only id to
toggle bookmark state.

Start a blacklist, which should remain small, for these components.
Intuit the next page when logging in at the RT web root

Forcing the next page to WebURL, or even WebPath, loses the potential
query parameters to index.html.  Perhaps most common is the URL

    /?q=foo

for a quick search.  It was previously lost during the login flow.
Abstract away reading $session{NextPage} into two functions

Setting is already wrapped, but reading was direct.  Following commits
will use FetchNextPage for display.
Anticipate storing more information about the next page in the session
Check the original request for side-effects before prompting for login

Sets the foundation for informing users about to login what will happen
after they do so in order to help prevent phishing.

Note that while this shares some code and config with CSRF, it _isn't_
CSRF since the user is not yet logged in and it requires a user to fill
in valid credentials.  Sharing config allows administrators to whitelist
external sites, such as corporate portals, which deep-link into RT, thus
preventing RT from crying wolf to the end user about legitimate
requests.
Inform the user logging in about potential side-effects

This helps prevent phishing where the user follows a malicious link and
isn't logged in yet.  Previously there was no indication of what would
happen after login.  The CSRF protection does somewhat double duty and
provides the same measure of phishing protection when the user is
already logged in, but it is never triggered by unauthenticated
requests.

The warnings on login are controlled by the same configuration as CSRF.
Include the potential request's action in the CSRF interstitial

We now have the means to be slightly less vague than "perform actions".
Load the Class as the current user when creating Articles

We use the loaded class to check the CreateArticle right, which is
always true for the system user.  This enabled any privileged user to
create articles in any class that existed given a crafted URL.  Only the
core article fields were usable (Name, Summary, Class), since custom
fields are protected by independent rights.

Resolves CVE-2012-4731.