move helpers into RT::Test from a test file
validator: create Principal in force resolve mode

If principal is missing in {Group,User}->Principal relation then
user have two choices: delete pointing object or create
new principal record. It was decided to do nothing in auto-force
-resolve mode. However, absent principal means that $group->Disabled
returns undef and we use that call in other places. undef may cause
infinite loop while trying to restore other records, for example CGM.

prompt_action is only used in this place, so it's ok to change its
behavior.
test edge case in validator
Add a timeout to prevent failing inifite loop tests from hanging forever
Fix precedence errors found by perl 5.19.4 of return ... or ...
Cwd::realpath("/nonexistant") on 5.19.4 returns undef
Catch and warn about template compilation errors

RT warns when saving a template which fails to compile (for example, due
to improperly closed braces).  However, if this warning is ignored (or
the template was imported by hand from initialdata), the only hint as to
this came at the debug level:

    [debug]: Skipping Scrip #7 because it didn't Prepare

Make the template compilation error explicit, and show which template
contains the error.
Account for new compilation warning
Allow member addition in initialdata
Bullet-proof upgrade steps slighty, by dropping if the new table exists

It is not uncommon to conduct a test upgrade, and then re-import the old
data stop.  Because the backup contains 'DROP TABLE IF EXISTS ...' for
the tables that existed in 4.0, this _mostly_ resets the database -- but
leaves in place any additional tables that were created during the
upgrade process.  Upon the next upgrade attempt, the process aborts
because it cannot re-create table which was not dropped.

While the most correct fix is to drop the database and re-create it with
the backup, ensuring a pristine restore, this failure more can be
ameliorated by attempting to drop the table before creating it.

All backends except Oracle support DROP TABLE IF EXISTS, so use it.
While it is possible to approximate DROP TABLE IF EXISTS on Oracle,
doing so requires stored procedures, which the RT user may not have
rights to run.  Since this is merely additional bullet-proofing, the
inability to run it safely on Oracle should not halt the additional
protections on other databases.
Respect transaction squelching for signing/encryption
Ensure that panes are displayed in a stable order

'keys' on a hash is no longer stable in recent versions of Perl.  As
such, the display order of the panes (as pushed onto @panes at the end
of the block) was no longer stable.  This caused the Sidebar and Body
sections to randomly flip back and forth as a portlet was moved up and
down in them, or other edits were made.

Sort the panes by name, to ensure consistent display order.
_EncodeLOB expects to get an octet string.

We were passing the character string returned from _DecodeLOB and
persisted by Storable.  This caused checks of validity to fail and
things that should have been encoded in Quoted-Printable to instead end
up being passed directly to PostgreSQL which kicks them back as invalid
UTF-8.

Combined with our change to _DecodeLOB to now strictly decode to UTF-8
and apply Encode::PerlQQ, we should no longer be able to pass invalid
data along to the database.  The Encode::FB_Croak enforces this before
we get to the DB.
Ensure that all calls to _EncodeLOB pass bytes, not characters

There are several places that call _EncodeLOB; most are careful to pass
bytes, not characters:

  1. RT::Attachment->Create takes a MIME::Entity; while the transfer
     encoding will have been decoded, ->bodyhandle->as_string does not
     decode bytes into characters.

  2. ObjectCustomFieldValues from file uploads; these are always left as
     bytes.

  3. ObjectCustomFieldValues from Content which is too long; Content is
     passed as characters.

The one codepath which currently might pass characters, and not bytes,
is the third possibility.  While the Mason parameter munging in
RT::Interface::Web ensures that invalid byte sequences (including for
invalid codepoints, like \x{FDD0}) are replaced using PERLQQ, there are
no such guards for character strings passed to ->AddCustomFieldValue
directly via the API.

Ensure that the LargeContent passed to _EncodeLOB, upgraded from
Content, contains bytes and not characters.
Correct old "Queue" and "QueueId" columns which still assumed scrips applied to 1 or all queues
Allow queue CF rights to apply on single-queue searches

Because of the lack of context object, granting a user SeeCustomField on
a queue was insufficient to cause its CFs to appear if the search was
limited to that queue.  While CFs cannot currently have more than one
context object (as would be necessary in the case of a search over
multiple queues), the usability can be improved in the common case of a
limit on a single queue.

Apply the relevant queue as context object to CF limits when searching
within a single queue.  This allows "SeeCustomField" on the queue level
to be respected in the SearchBuilder.
don't bother searching users at all without search term

without this, the page could hang(query could take a lot of time) if users
number is huge.  (I got bitten with 700,000 users before)

technically, when there is no $UserString, though RT::Users::SimpleSearch
directly returns, the following $users calls like "$users->First", etc will
still query the db, which is both time-consuming and unnecessary in this case.
Stop leaking an extra dbh during server startup

RT::Handle->CheckIntegrity is called during rt-server startup, and its
return value is is stored in $integrity.  Additionally, $RT::Handle is
explicitly destroyed, to ensure that the database is disconnected before
forking.

Unfortunately, this replies on the dbh going out of scope, and
disconnecting during its DESTROY.  As the dbh is stored in the
$integrity variable in addition to $RT::Handle->dbh, it never goes out
of scope, and is thus never disconnected.  For fastcgi deployments, this
causes every fastcgi process to hold open an extra database handle;
standalone servers only ever gain one extra handle.

As no callsite of CheckIntegrity relies on the $dbh return value, simply
return true.  This allows the database handle to be disconnected using
$RT::Handle->dbh(undef).
Explicitly disconnect the dbh before forking, if it exists

This remoes the reliance on disconnect-on-DESTROY, and ensures that the
database handle is disconnected even if outstanding references to
$RT::Handle->dbh still exist.
Don't start a FCGI process manager unless one is needed

Plack::Handler::FCGI checks for a true "listen" value to determine if a
FastCGI process manager is necessary -- this is usually only needed in
the case where the plack process is being run as an "external" fastcgi
process, which will fork multiple subprocceses and communicate with the
webserver via a fixed endpoint (local port or socket on disk).  It is
unnecessary when the process is started by the webserver, and the
communication is via STDIN.  While unnecessary, it does work, however.

The refactoring in 6c15e8a3 removed the following line and comment:

    ### mangle_host_port_socket ruins everything
    delete $r->{options} if $is_fastcgi;

It was replaced with an override of mangle_host_port_socket.  In doing
so, "listen" for the case of reading from STDIN was set to an empty
list, rather than to a false value.  This caused the aforementioned
FastCGI process manager logic to kick in.

Restore the previous behavior, and drop the unnecessary FastCGI process
manager, by ensuring that "listen" is not set if no listen sockets have
been provided.  This also has the useful side-effect of restoring the
process name (as seen via `ps`) to be the path to rt-server.fcgi, and
not the static string "perl-fcgi-pm" with a "perl-fcgi" subprocess.