don't trigger default warning handler for inline servers

we already handle server warnings in StashWarnings middleware, so it's not
necessary to do so. without this, under TEST_VERBOSE=1 mode, those warnings
will be bubbled up to Test::NoWarnings handler, which could cause
Test::NoWarnings::had_no_warnings() to fail.
remove diag call in RT::Test::file_content

the main reason to remove it is it causes t/web/cf_access.t to fail no
warnings tests under TEST_VERBOSE=1 mode. the warning is like:

    Name "RT::Test::TODO" used only once: possible typo at .../Test/Builder.pm line 2244

though we can also get around it by increasing $Test::Builder::Level in
RT::Test::file_content or never call file_content in compilation stage(e.g. in
a BEGIN block or "use constant ..."), imo it doesn't worth it.
keep "add principal" input be focused when it's been clicked

when clicking the "add principal" input (e.g. #AddPrincipalForRights-group),
anchor will be synced to #acl-AddPrincipal, but the input focus will be lost
too(at least on firefox).
Remove caching of template objects in rt-crontool

rt-crontool has cached lookup of the the name of the template ever since
3.8, when the ability to specify a template by name was introduced.  The
template object is modified in memory when ->Parse is called, however,
updating its ->MIMEObj.  This was not a problem because
RT::Action::SendEmail->Prepare calls ->Parse, which clears out its
->MIMEObj.

Unfortunately, a1a4f73e caused Template objects which already had a
MIMEObj to retain them.  In the context of rt-crontool, this causes the
same content (that formed from the first matching ticket) to be sent out
on all tickets whenever RT::Action::SendEmail is used as the target
action.  RT::Action::RecordCorrespondence is unaffected, however, as it
always calls ->Parse.

Remove the unnecessary cache in rt-conjob; looking up a Template objects
per RT::Ticket result is unlikely to result in performance implications,
as it is a small and well-indexed table, and caching repeatedly proves
to be complicated to implement without unexpected side-effects.

Fixes I#29454.
lock rt-fulltext-indexer so only one instance can be run at the same time

multiple instances eat more cpu and may also break stuff.

see also #17423
Re-indent _EncodeLOB and _DecodeLOB
Respect the database Content-Type header in decoding textual parts

The definition of "texual" data has changed over time.  Specifically,
7365c08 caused text/html messages to begin being stored as utf-8 in the
database; prior to that, the claimed "charset" and bytes in the body
were left unmolested during insertion.

text/html attachments inserted into the database prior to 7365c08,
however, are now expected to be utf-8 when being extracted from the
database.  This causes PERLQQ'd garbage to be displayed for the non-UTF8
content stored in the database.  This type of error is likely to also
re-occur in the future whenever the definition of "textual" data
(i.e. data we transcode on insertion) changes.

Respect the Content-Type header when decoding data from the database, or
guess its value from the body; this mirrors the logic in
RT::I18N::SetMIMEEntityToEncoding, which is what is done for
currently-detected-as-textual parts on insert.  In cases like text/html
prior to 7365c08, the Content-Type header was not altered during
database insertion -- and at worst, the claimed character set is
incorrect and decoding will result in PERLQQ'd garbage.  This is no
worse than said message were detected, received, converted, and stored
in the database as text.
Stop needlessly frobbing utf8 internals

bf87c784 swapped in this explicit _utf8_off for what had been a
_utf8_on.  As the values are fetched with decode_utf8 => 0, $content
contains bytes, not characters.  Explicitly turning of fthe utf8 bit is
unnecessary, as they are already bytes.
Decoding content, and returning characters, is incorrect

The whole purpose of this function is to return bytes, not characters.
Decoding the bytes to characters as utf8 defeats the purpose, and only
works because RT's internal representation of characters happens to be
utf8, which gets used by MIME::Entity to later encode the characters.

Switch to simply returning the bytes, as-is.
Stop assuming the data in the database is utf8

As noted in 18c810d0, not all content we currently call "texual" was
always treated as such.  When re-encoding, do not assume that the
encoding in the database is UTF-8 -- rather, read the Content-Type
header, and examine the charset stated there.  Convert from that to the
original encoding.
avoid adding repeated cf values

now RT::ObjectCustomFieldValues::HasEntry compares LargeContent and also
canonicalizes values before comparision when possible.

see also #4553

btw, there was a bug that if you change a date cf from "2014-05-15" to
"today"(which also means "2014-05-15" at that time), you will get a confusing
message saying "2014-05-15 changed to 2014-05-15". this commit fixes it too.
add --quiet option to make fulltext-indexer more convenient in cron env

so we can exit processes quietly and normally.
tests for repeated values
Minor wordsmithing, and copy the paragraph to Oracle as well
Merge branch '4.0/lock-fulltext-indexer' into 4.0-trunk
Merge branch '4.0/admin-rights-add-principal-input-focus' into 4.0-trunk
Merge branch '4.0/remove-test-file-content-diag' into 4.0-trunk
Bump the Plack::Middleware::Test::StashWarnings dep for "verbose" option

As this is in developer dependencies, there is no harm to doing so in a
stable series.
Merge branch '4.0/stash-warnings-verbose-option' into 4.0-trunk
HasEntry canonicalize values now, so no need to explicitly do that any more