This commit addresses a vulnerability on how osTicket authenticates
auth-tokens used for auto-login to view ticket status.

The validation process failed to handle unexpected type handling issue
making it possible for users to exploit type juggling and authenticate using
only email and ticket number.

This adds a Signal to clean Agent and User sessions upon setting/resetting
their password. If an Agent/User resets their own password and has multiple
sessions open it will log them out of every session except the one they’re
on.

This addresses issue 4073 where Disabling the 'Excessive failed login
attempts' option in the Ticket Alert settings will still send the Admin
Excessive failed login alerts. This is due to the method that checks if
the setting is Enabled returns `0` or `1` not `TRUE` or `FALSE`. So this
updates the section of code to return `FALSE` for `0` and `TRUE` for `1`
so that it properly disables/enables the alerts.

Fix for  Auth Ticket generation & check mismatch #3005

This is my attempt at removing similar texts from the translator work load.
It also makes an attempt at dropping some misspelled words and works toward
standardizing some phrases.

Add ability to disable use of authentication tokens on ticket links

Also fix clobber of password reset user ID's in config table, and fix
cleanup of client password reset tokens from config table.

This adds the concept of a PasswordPolicy registration system, which
provides an extensible way of administering and configuring password
complexity policies.

It also adds a setPassword() method for the authentication backends which
will allow for the respective backend up update the password according to
whatever method is suitable for the respective backend (such as remote
updates for LDAP).

Allow fields to be configured for view / edit / required for both agents and
end users. Fields can also be disabled now so that the field remains in the
form but is no longer displayed for new entries.

Allow tickets to be created without a subject — use the help topic full name
instead.

This patch adds support for automatic date and time formatting based on a
selection of locale. The locale can default to the system or user specified
language+locale, or can be elected separately. For instance, English
speakers can pick between US, GB, and many other English speaking locales.

This also removes the need of the %timezone table and uses the timezonedb
built into PHP 5.3+. User's can now select from a much longer list of
database and no longer need to deal with the DST checkbox.

This will help if the user has "Browser Preference" selected as the
preferred language. When email correspondence needs to be sent to the user,
the browser_lang extra attribute can be used as a backup to to the user's
language preference in the event that the language preference is set to auto
(Browser Preference).

Starting with osTicket 1.8.1, users must receive an email and follow a link
in the email to get access to the ticket. With this new option, the email
verification step can be avoided in osTicket 1.9, because access is now only
granted to exactly one ticket.

Previously, once a client was authenticated to the system with an email
link, the user could utilize other email links to other tickets; however,
the same ticket page would be presented to the user regardless of which link
was utilized.

This patch allows the ticket in focus for the user to be changed after
visiting the client portal with a different ticket link.

DISABLE_SESSION define is changed so that existing session are continued
but new sessions are not saved. This allows external auth backends to
redirect to an external site and that site redirect back to a `/api` URL and
the user's session will be continued.

Support searching both staff and user backends via a common interface.

Regardless of the configuration of the help desk registration, allow users
to receive ticket links via email. This patch enables the display and
operation of the ticket access link unless a user login is requested by the
user or specifically required by the system.

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 make writing new backends (such as LDAP) easier and less copy+pasting
is required.