Protect against an undefined warning, as $args is not required
Support testing-only plugins by looking under t/data/plugins

Plugins written as part of the test suite can be enabled with:

    use RT::Test plugins => ["Foo"];

provided t/data/plugins/Foo/ exists.
Test plugin loading and lib overlays in plugins via rt-server

Currently failing because RT::User is loaded too early.  Requires
testing under apache because otherwise the RT init sequence in the test
process (via RT::Test->import) interferes with rt-server in a way that
causes it to pass.

It is far too easy to break certain lib overlays when provided via
plugins, so hopefully a simple test will help.
Plugin paths MUST be in @INC before we do anything else when firing up the server

Otherwise plugins can't reliably use lib overlay files (_Overlay,
_Vendor, _Local) as the core classes won't be able to find those
overlays at load time.

Normally RT->Init() takes care of this early on, but we postpone calling
Init() quite a bit, notably until after calling CheckIntegrity().  The
CheckIntegrity() call ends up loading RT::User and other classes, which
means they went looking for overlays before lib paths were setup.
Bulk update: Only show statuses for queues which appear in the results

Trims down the status selector from "all statuses" to a potentially much
smaller set in many scenarios.  It's safe to limit selectable statuses
because Status is set _before_ Queue when processing the update, so all
valid statuses will be listed.  If Queue is ever processed before
Status, this change will need to be revisited as it prevents showing
statuses from destination queues which don't appear in the search
results.
Group by lifecycle in the status selection widget

For UI simplicity, no grouping is done if only one lifecycle is seen.

For code simplicity, multiple <option> elements may be marked selected
even if the displayed <select> doesn't allow multiple selections.  This
is an authoring error according to the HTML spec, but browsers generally
just deal and pick one.  It doesn't matter to RT which one they pick,
since statuses are identified only by name.  We can consider a technical
solution down the road if it proves to trigger confusing behaviour and
frustrates users.
Simplify status selector by lumping lifecycles with identical statuses

For example, the "default" lifecycle and a copy named "reply-on-resolve"
which changes only the transitions available in the actions menu are now
grouped into the same <optgroup> with the heading "default,
reply-on-resolve".

While the previous commits made the shipped "approvals" and "default"
lifecycles appear separately if you were looking at tickets in both
queues, this commit now joins them.  For maximum simplicity, the
decision to display groupings or not is done _after_ simplification,
regardless of how many lifecycles may be lumped into the same grouping.
Tests: Useful diagnostics for failed status selector tests
Tests: Statuses may now show up multiple times in the selector widget

Checking for the duplicates is better than weeding them out since it
ensures the grouping logic is working correctly.  Unfortunately
HTML::Form (and hence WWW::Mechanize) provides no means to check
<optgroup> easily.  Ideally we'd check the presence and order of the
combined keys "<lifecycle name>-<status>".

Tests now pass.
Verify all tests are warnings clean using Test::NoWarnings

An additional test for each test file is run either in the existing END
block during test cleanup or in done_testing(), whichever comes first.
Whenever possible, the single additional test is automatically accounted
for by RT::Test.  This means most test counts do not need to change.

Tests which declare a plan using Test::More and _also_ use RT::Test need
to manually account for the extra test themselves since the plan is
already output before RT::Test is ever called.  This is mostly the
shredder tests.
Catch specific warnings emitted by three test files

Tests should now be warnings clean once again.
Provide a Log::Dispatch->warn which works on Log::Dispatch 2.23

Though Log::Dispatch 2.23 added the ->warn alias for ->warning, until
version 2.30 it failed to correctly canonicalize the level internally,
and thus failed to ever usefully generate output.  All of the warnings
added in 0acc888 thus only appear on Log::Dispatch 2.30 and above, due
to this bug -- and consequently the newly-added 'warning_like' tests
fail with earlier versions.

Rather than increase the minimum Log::Dispatch version during a stable
series, provide a thin shim for ->warn which calls ->warning, which
works as expected.
Also wrap ->err and ->crit to ->error and ->critical
allow "requestors" because it's a valid field

in 4.0/cli-create-ticket-with-unknown-field, we added extra guard to
throw errors if there are some fields unknown. we missed "requestors"
field there, which is actually valid.

see also #21552
test for requestors field from rest
Change our to my in create ticket template sample.

Update the create ticket template example to use 'our' and
explain the scoping for variables in perl blocks.
Clarify documentation for Content line in create ticket templates

Clarify description of param/value syntax in templates,
specifically that values must come right after the param even
for the Content: param. Fix example to follow this rule.
Clean up create tickets documentation
Further minor cleanups to the CreateTickets POD

• Be consistent with identifiers we refer to in the same ¶
• Use more C<> formatting around identifiers
• Link to the Parse method when we refer to it, which necessitated
  cleaning up the Parse pod
• Perl not perl when referring to the language.
Merge branch '4.0/correct-createtickets-docs' into 4.0-trunk