This adds a setting in the Ticket Settings to give the option of showing the
ticket counts on Top-Level queues. If enabled, this will populate the ticket
counts next to the Top-Level queue names like they used to be. The only
caveat is the counts are triggered by mousing-over any of the queue names as
we only load the counts when we need to display the sub-queues (for better
performance).

This also adds a new format function called `number` (Phase 1). As of now it
will format any integer to a comma separated number (eg. `1337 -> 1,337`).

issue: ticket_link Fatal Error

Queue counts

This addresses an issue where replying to a ticket causes a Fatal Error for
the system. This is due to the `$ticket` object not being set before the
else statement therefore causing the `getId()` function to fail. This breaks
down the if/else statement to make sure the `$ticket` object is in-fact set
before continuing.

Dashboard Statistics Issue

This commit fixes an issue where we were not able to see all of the departments, topics, and agents that should have been included in the report. The logic for the  GROUP BY in the queries was changed, so we just manually added them back in.

This commits adds fallback for queue counts and improves caching mechanism.

issue: Dupe Page Requests Fix

Add new API headers to whitelist

upgrade: Actually re-fetch the config from database

issue: Delete User Error

This addresses an issue reported on the forum where deleting a User will
throw a fatal error. This was caused by 4558 where the `state` column was
mistakenly overwritten with `event_id`. In addition, this changes `$deleted`
to `$status_id` for better readability.

issue: Export Event State Error

This addresses an issue where export does not work due to a fatal error
"Unknown column 'R0.state' in 'where clause'". This was caused by 4558 due
to the removal of enums and the `state` column. This updates the filter to
match the `event_id` instead of `state`.

This addresses an issue with pull 4472 where disabling the Submit button
does not submit the Input value for the button. This affects the
installation of plugins, where the Install Path is not sent therefore the
plugin is not installed. This clones the original submit button, hides it,
then displays a dummy disabled Submit button which will submit the value and
prevent dupe posts.

This patch fixes the issue where the configuration was not properly
reloaded during an upgrade. The configuration items were stashed in the
Config class and were not re-fetched from the ::load() method.
Additionally, this patch forces the ORM cached objects to be flushed on
each loop through the automated upgrader to ensure that cached data
which might have been modified directly in the database during the
database process is destroyed.

oops: put back missing code

Event Migration Optimization

Issue/remove enums

Primary Queues as "Buckets"

Clear cached queue counts on queue update and via auto-cron

This commit reverses relevance limit added by commit a9c283ec. This is
necessary because searching for Organization or User name will have low
relevance due to limited size of indexed "document".

Drop checking FLAG_PUBLIC when determining if a queue is private

This commits adds ability to add extra joins to a queryset. If the join has
constraints then it's LEFT joined otherwise straight JOIN is assumed.

This is necessary to fix queue counts for queues with keyword search.

Now that pjax has been in osTicket for quite some time, it should be
assumed that requests made with pjax will work and a response can be
waited for. With a very low timeout of two seconds, operations that take
more than two seconds are cancelled via pjax and then re-requested via
normal page load. This has the caveat of running large database queries
twice, since some long-running ones cannot be cancelled by the database
until the first results become available. Therefore, queries which take
a while to find the first record (longer than two seconds) will be run
twice. Ultimately, the user will have to wait at least twice as long as
would ultimately be necessary if the system had just waited for a
response from the pjax request.

This sets the timeout at a more reasonable value of 30. Perhaps
something closer to a minute would be a suitable value? Most users are
probably going to click something before 30 seconds expires if they
expect a response faster. And that can't be easily fixed.

This is pretty weak as implemented, but one of the problems with
searching speed is that, for each page render, the count of the hits is
required. But now the hits query does not actually collect the count for
the search queue. What's worse, the code collects counts for all saved
queues (not including the advanced search), so the counts are not
included. Then, the code re-collects the counts for all the queues since
the advanced search queue count isn't available. Then, since there still
is no count for the advanced search, it will show "0" results after
waiting to count all the other queues.

This cowardly fixes the issue by assuming there are 500 hits, which
allows a few pages. In reality, the pagination system should be rewired
so that it can dynamically add pages until it comes up with a short
read of results, in which case it can assume that it has reached the
end.

This patch adds a few changes. First, the full-text search query is
refactored so that MySQL can focus first on finding matching records in
its full-text search index (in the %_search table) in a subquery. Then
it can focus on matching records against tickets in an outer query
(whether ticket data, thread entries, user info, or organization inf was
matched).  This dramatically speeds up the query for large datasets by
about 20x (about three seconds instead of sixty-something).

Secondly, results are now sorted based on relevance, so the best hits
sort a the top of the list. This is accomplished by adding the
`relevance` to the query sort list via the extra() method. Then, since
no GROUP BY clause is really necessary, it is not added to the query,
which will allow the results not to be re-sorted by the ticket_id. (That
is, the remain sorted by the search relevance).

Third, the relevance has a lower limit of 0.3. Good hits seem to have a
much larger value (like hundreds), so setting a small value will help to
remove hits with barely any relevance to the search terms.

When using a nested query to perform the search for the ticket queue, drop the extra
full-text search criteria join from the outer query. This seems to drop the
`rows_examined` by a factor of two and drops the query time by an order of
magnitude.

This significantly speeds up the re-indexing speed for large databases. Since it is
only important to have the system reindexed--and not necessarily what order the
re-indexing happends, the sorting is really just a waste of resources and time.

This dramatically increases the performance of searching for indexable threads, for
instance, from 260900ms to about 42ms.