When following a link from an email, if you are already signed in to the
help desk as a client, you should just be redirected to the new ticket.

Useful if the staff members administratively configure a static password
that the user should never change.

This adds a feature for remote authentication methods for clients, such as
LDAP, which will, after successful authentication, yield a
ClientCreateRequest rather than an AuthenticatedUser. The
ClientCreateRequest represents a successful authentication and user
information lookup for a remote client. The client is then presented with a
registration page where their information for their account in the local
system can be reviewed prior to the account creation. Once created, the
client account is confirmed without an email confirmation and is logged in
immediately without reentering a password.

This is the mode of the system if account registration is disabled

If a client is already logged into the client portal and attempts to submit
a new ticket, the ticket will be rejected if the contact-information form
has a required field other than `name` and `email`.

This patch fixes `class Client` so that the user-id is fetched from the
database and made available via the `::getUserId()` method. This was already
corrected in the `develop-next` branch for v1.8.1. The `uid` field is passed
into `Ticket::create()` so the user form validation is bypassed.

This commit should be ignored when merged into the 1.8.1 codebase.

Ticket owner as well as collaborators can request access link by entering
email and ticket number.

Reafactor logOut to use the piggyback on auth backend

The main intension is to have a predictable length and position of
the ids - obfuscation is a welcomed side effect.

Add EndUser lookup by email to TicketUser - returns a decorated user

TicketUser class - Abstract class with auth token implementation
TicketOwner class - extends TicketUser

Add user ticket stats to EndUser class

Add ability for backends to set authorization key (authkey) specific to the backend.
The authkey is tagged with the "id" of the backend that generated it.

Add token (authtoken) based authentication to User authentication backend.

in Client::getLastTicketIdByEmail()

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.

*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.

* No longer redirects - simply returns usersession obj.
* support error setting - shown on login page in place of "Authentication Required";

change tryLogin to simply login