This patch partially reverts the previous database migration patch which
added a primary key to the table on the `thread_id` column. This column
cannot be used, because there may be multiple entries for thread_id = 0.

This also allows ticket_collaborator.isactive to be negative, as well as
adds the database portion of regex support for ticket filters.

Delete junk records from the %ticket_email_info table before adding a
primary key. Since there was previously no PK, there could be duplicate
records.

Add `attrs` field for backend state information (multi-part migration,
multi-part upload, etc). Change `size` to be an integer rather than text
field. (Storage space will be about the same, but int makes more sense).
Size the `key` and `signature` for ~512 bits. The base64 encoding allows
6-bits per char. At 86 chars, we have 516 bits maximum space.

Fixes the rewriting of the `key` field in the ticket thread body. The
storage de-duplication system may replace the `key` value with an existing
one. The ticket thread system will use the `key` value assigned when the
file is committed to the database or the existing key of the duplicate file.

Also fixup installation issues with the attachment storage plugin
architecture

  * Include a `bk` column to store the storage backend
  * Include a `signature` column which represents a repeatable hash of the
    file contents
  * Rename `hash` to `key` since it isn't a real hash

Conflicts:

	include/upgrader/streams/core.sig

And add fixup rebase conflicts, and add nice page for unconfigurable plugins

There's a unique index on %user_email.address, so there's no need to create
an index on %ticket.email when matching up records.

Fix duplicate phone number (again)

  * Require a label on form fields
  * Require variable name to be unique per form
  * Fixup duplicate phone numbers on upgrade

formset_id was not renamed to form_id after our rebase

Wrap the upgraded email template data in an HTML <div> element so that the
final content is valid HTML. This is useful for the mailer to identify the
message content as HTML

Fixup several minor bugs concerning initial experience

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 is a major redesign / rework of the osTicket base*

This patch drops the concept of static ticket metadata and allows for an
admin-configurable arbitrary data that is attachable to tickets

The system is architected such that the base osTicket install now comes with
a "default" form that has fields for subject, name, email, and phone number.
This form is editable to allow for the addition of arbitrary other fields;
however, the basic fields must remain in order to be associated with a
help-topic and attached to a ticket.

This concept can be expanded to allow for arbitrary data associated with
registered clients or ticket thread items.

Forms are comprised of sections. Sections have a title and instructions
properties and a list of fields. Fields have various implementations to
represent different data such as text, long answer, phone number, datetime,
yes/no, and selections, and are configurable to define the look and feel and
interpretation of the respective form field.

Dropdown lists are represented as "Dynamic Lists", which are
admin-configurable lists of items. Dropdowns can be optionally represented
as Bootstrap typeahead fields.

This also adds the start of a simple ORM which will hopefully be expanded in
the future to support multiple database platforms. Currently, only MySQL is
implemented.

Process inline attachments in thread entry and support inline images in
piped emails

Support inline images across the system, with draft support

Migrate to a single attachment table
    That way we don't need a new table for everything we need to attach an
    inline image to (like a signature, for instance)

Add richtext support for internal notes

Implement images on site pages

* Image paste in Redactor
* Make non-local images optional
* Placeholder for non-local images
* Fix local image download hover
* Don't re-attach inline images

This is one of the last major hurdles to make osTicket fully translatable.
With the advent of 1.7.0, database migration is based on the MD5 hash of the
install SQL file. Therefore, the install SQL script cannot be modified (ie.
translated) or else the system cannot be migrated, since the MD5 hash will
no longer match up.

This patch pulls initial data out of the install file so that it can be
translatable. Eventually the install worksheet can allow a drop-down box of
the default system language. The default data from that language will be
loaded into the system.

Anything that would happen after the last patch was applied would never be
logged, because the system would immediately indicate that no upgrade was
pending.