This is not only for code consistency, but also for consistency of
output.  Encode::encode_utf8(...) is equivalent to
Encode::encode("utf8",...) which is the non-"strict" form of UTF-8.
Strict UTF-8 encoding differs in that (from `perldoc Encode`):

    ...its range is much narrower (0 ..  0x10_FFFF to cover only 21 bits
    instead of 32 or 64 bits) and some sequences are not allowed, like
    those used in surrogate pairs, the 31 non-character code points
    0xFDD0 .. 0xFDEF, the last two code points in any plane (0xXX_FFFE
    and 0xXX_FFFF), all non-shortest encodings, etc.

RT deals with interchange with databases, email, and other systems.  In
dealing with encodings, it should ensure that it does not produce byte
sequences that are invalid according to official Unicode standards.

While in all of these cases, the number in question is guaranteedly
plural, non-English languages may have more interesting rules for
pluralization nouns than simply "singular" or "plural."  As such, use
quant() even when the value in noun form is invariant in English.

The md5 method expects a sequence of bytes.

Principal ids should be the same as their associated user or
group id, so save the id of newly created principals in the
RT::User and RT::Group PreInflate calls to be used when the
user or group record is created.

This was unintentionally removed in 68c3906e

The bcrypt key derivation function only uses the first 72 bytes of the
input; when used directly on a password, this effectively limits
password length to 72 characters.

Allow for arbitrarily long passwords by hashing the password using
SHA-512 (which produces 512 bits, or 64 bytes, of output) before passing
it to bcrypt.

A SHA-512 with a 16-character salt, drawn from 64 possible characters,
yields 2^96 possible salts.  While this makes rainbow tables unrealistic
given modern hardware (the failure mode of RT 3.8's MD5 hashing), it
does very little to deter against offline brute force attacks on the
database.

Specifically, given the complete hashed password and salt from the
database, a dictionary of weak passwords can be hashed with the stored
salt to attempt to find matches.  Given that a single round of the
SHA-512 hash is not designed to be computationally expensive, possible
passwords may be hashed and checked very quickly.

The bcrypt hashing function is designed to be computationally expensive
to mitigate these types of attacks.  For instance, on a development
laptop:

                   Rate   bcrypt  sha-512
        bcrypt   3.34/s       --    -100%
        sha-512 36850/s 1102153%       --

That is, bcrypt is four orders of magnitude slower to compute, thus
notably increasing the computational cost of brute-forcing passwords.
bcrypt also includes a tuning parameter, the number of "rounds" to run,
which allows the same algorithm to be increase the computational cost
required as computers continue to grow faster.  We use the standard
value of 10 here, but allow for higher values to be used later.

As SMIME support requires that the private key for a user be in a .pem
file named with the email address, there can be only one private key for
a user at a time.  As such, PrivateKey (which also expects a ->{Key} on
key informational hashes, which SMIME lacks) and SetPrivateKey are
meaningless.

RT::Crypt is loaded unequivocally during the PostLoadCheck; no other
codepath need load it.

This will allow subclassing of different RT::Crypt::... classes.

otherwise, it returns useless "2"(the list size) or the last item(i.e. message).

now we can easily check if ->Load succeeded or not, for example,
$principal->Load(...) or Abort(...)

In order to reduce confusion with the common extension
RT::Authen::ExternalAuth, the following options have been renamed:

  WebExternalAuth           => WebRemoteUserAuth
  WebExternalAuthContinuous => WebRemoteUserContinuous
  WebFallbackToInternalAuth => WebFallbackToRTLogin
  WebExternalGecos          => WebRemoteUserGecos
  WebExternalAuto           => WebRemoteUserAutocreate
  AutoCreate                => UserAutocreateDefaultsOnLogin

This also makes their utility more evident.

At the same time, make a few more useful attributes public under the
assumption that if you're putting it into RT, you want to be able to use
it.  The public accessible check still lets _LocalAccessible overlays
specify public => 0.  We start with a static set of fields rather than
RT::User->ReadableAttributes since most of the user attributes are
~useless for grouping.

3cd39ce6 refactored HasBookmark into RT::User from RT::Ticket, but in
doing so inexplicably made it into a tautology; if any one ticket was
bookmarked, all tickets passed to HasBookmark would return true.

Return to the pre-3cd39ce6 logic, which is correct.

The "concise" format, when originally introduced in 07ec5dc4, contained
similar logic which depended on the state of ->Privileged.  However,
this was removed in 20d879f2, after it appeared to incur a notable
performance penalty.

However, upon closer analysis, much of the penalty was incurred by the
need to render the names of several hundred users for the ShowUser
dropdown -- a configuration which causes performance penalties
regardless.

At a possible minor performance cost, use the Privileged bit to control
how users are displayed.

These formatters generally deal in just text, not HTML, and they can't
be used by other library code when written in Mason.

see also #18722

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.

Short-circuit the class-specific logic in Serialize and PreInflate if
cloning is in progress.  These custom class-level methods all deal with
doing ID => UID translation, or ensuring that duplicate records are not
created, neither of which are necessary when cloning.

The change in b4d0382e caused failures during import on users, as it
mis-named the column to attempt to load on.

When a group becomes disabled in RT, we mark all CGM rows that existed
because of that group as 'Disabled'.  Unfortunately, many joins through
CGM neglected to take the Disabled column into account, leading to users
possibly having rights that they should not, due to having them by way
of a disabled group.

This addresses CVE-2011-4459.