Under certain intermittent circumstances (usually a significant number of
ORM queries), the ORM will trigger a MySQL error:

Commands out of sync; you can't run this command now

Usually this MySQL error is related to buffered versus unbuffered queries.
However, the ORM already uses buffered queries (MySQL calls it
"store_result"). In this case, it appears there is some sort of race between
fetching the result metadata before configuring the statement for buffering.
(By "race" I mean that the error is not reliably triggered).

This patch seems to fix the issue by configuring buffering before fetching
result metadata — necessary to configure the fetching (output) phase of the
statement.

Statuses with tickets cannot be deleted
Fix orm to class gracefully when joins are not inspected
Add create date to new statuses

Ticket numbers are now configurable as a system-default and by help topic.
Previously, an administrator could select between six-digit random and
sequential numbers. Now, the sequence is selectable so multiple sequences
as needed, and a format can be specified to define how the ticket numbers
look. Formats can also be defined for each help topic.

User::fromVars in class ticket was the root. Eventually, in
DynamicForm::getDynamicFields(), isset($this->id) was used to detect
unsaved, new forms that have not been committed to the database; however,
the isset() method was not implemented for the ORM.

Several places in the code initialize a list of objects from the database
and only fetch one item. In certain instances (which seem almost like a race
condition), MySQL will feel like there are more records available in the
database and will complain with "Commands out of sync, you can't run the
command now".

This patch addresses the issue by utilizing the ::one() method of the
QuerySet where only one record is expected. The ::one() method is further
designed to fetch all one results (which satisfies the MySQL client library)
and return the first item.

Conflicts:
	include/class.orm.php

Allows for backend listing, file listing, single file dump and file
migration.

This patch introduces an automatic materialized view to speed database
performance when querying and displaying the ticket views. This can
eventually be extended to the search and advanced search features to speed
them as well.

The data from the dynamic form entries related to ticket details is copied
to a %ticket__cdata table. The %ticket__cdata table is then joined directly
to the other tables in the query for the ticket view. MySQL is magically
and dramatically faster using this method.

The downside is that the disk usage for the custom data is doubled, and the
time needed to update the dynamic data is at least doubled as the form
entries and the materialized view must both be updated.

This method should also extend well to other database platforms in the
future. It will be likely that most other database query optimizers will
have difficulty joining, scanning, and sorting the table models we have for
custom data fields.

orm: Fix detection of statement failure
orm: Fix type detection of InstrumentedList::add
mysqli: Set object-level character set

without required, internal contact field

Use a PHP setup which uses the built-in PHP tokenizer to parse and traverse
PHP scripts to determine (possible) access to uninitialized variables

Including adding support to the TCL uninitialized variable reader to ignore
class-static variable access as well as detect inline functions and their
closure arguments.

Moved to an initial form which specifies the ticket's priority and issue and
changed the rendering to render things properly. Now the user can decide
where priority shows on the client side, and the priority privacy setting is
placed in the dynamic form wizard.

The standard form is added to every ticket without option. Extra forms can
be defined and associated with help topics which can additionally be added
to tickets upon creation. This allows for standardization of the dynamic
data location for searches and filtering.

Implemented advanced search for dynamic data. Along with reinstating the
basic ticket search on keywords

Implemented ticket filtering on dynamic data for both keyword searches as
well as searches for special fields (drop-down lists, etc.)

Phone number for users is now completely optional

This moves client information like name and email address out of the general
dynamic forms data for a ticket. It really paves the way for the first-class
user of the future.