Extract PO updates
Add =encoding directive, due to → character
Remove extra =item directive
Merge branch '4.2/pod-errors' into 4.2.0-releng
The file is charts.pod - without this we link to metacpan
make index management code case insensitive

with mysql on some systems table name in DDL queries
is case sensitive.
Merge branch '4.2/pod-errors' into 4.2.0-releng
$Watchers is a group; ->Type has been deprecated in favor of ->Name, since 71fcde3
Principal->ObjectId was deprecated in f70178f

Switch to using Principal->Id as suggested.
Allow for extra whitespace (such as \r) before end-of-line in certificates

Because we must decode the PEM format to DER before feeding to
Crypt::X509, we apply a regular expression to extract PEM data.
However, the regex must account for, and accept, \r\n-style newlines
which may arise from pasting content into the "SMIME Certificate" admin
interface.
Merge branch '4.2/watcher-type-deprecation' into 4.2.0-releng
Merge branch '4.2/smime-certificate-newlines' into 4.2.0-releng
Allow S/MIME enccryption to untrusted users with AcceptUntrustedCAs

gpg is incapable of sending mail to untrusted keys in its keyring.  For
this purpose, RT forbids sending mail to keys which have a trust level
of "unknown."  This limitation can be worked around by setting
'trust-model' to 'always' in GnuPGOptions, which forces all keys in the
keyring to be seen as 'ultimitely trusted' -- with the unfortunate
side-effect in such configurations that actually-trusted keys cannot be
differentiated from keys which are not.

S/MIME does not posess the limitation that untrusted keys cannot be used
for encryption.  In the case of AcceptUntrustedCAs, it is in fact a
somewhat expected workflow that an signed but untrusted S/MIME email is
injected, which may wish to be replied to with encryption.

Rather than implement the same solution as GPG (and suffer the
consequent loss of information as to signing trust), omit the TrustLevel
check if AcceptUntrustedCAs is set.
Merge branch '4.2/smime-untrusted-certificates' into 4.2.0-releng
values in table_name column can be case sensitive

It depends on file system and mysql setting.
Add upgrade history only if the database is known to be fully set up

Adding upgrade history entries requires that the tables have been
created and ACL'd, and that the coredata have been inserted.  'init' is
not the only way to be prior to that state -- the create and ACL states
can be run by hand, for instance.

Instead of assuming that the database _is_ sufficiently configured,
assume rather that is it not, and thus default to not logging upgrade
history attributes.  Only in cases where InitSystemObjects has already
been called (upgrades and non-coredata insertions) do we have a
guarantee that the database is sufficiently configured, and thus enable
upgrade history logging from then on.
Enable upgrade history logging for all non-RT database changes

There is one further condition, in addition to those in the previous
commit, under which we can be certain that the RT database is
sufficiently configured; namely, in the case of database changes for
extensions.  While logging for 'insert' actions in extensions is already
covered by the previous logic, 'acl' actions were not.

Explicitly connect and set up system objects when conducting database
changes for extensions; this then allows database upgrade steps to be
logged.
Merge branch '4.2/indexes-management-case-sensitivity' into 4.2.0-releng
Merge branch '4.2/version-history-bootstrapping' into 4.2.0-releng
Use custom field groupings on SelfService display page

For backwards compatibility, ungrouped CFs are displayed in the "Basics"
box after Basics and "Basics"-specific CFs.  This also moves the table
boundries to resolve [rt3 #26103], aligning all of the labels.

Note that the SelfService update page is unaffected, and does not
respect groupings.  However, all CFs are correctly displayed once, which
was not the case with the display page prior to this change.