Previously you had to click "Save Changes" for the count to be reflected on
ticket view page.

Pluggable storage infrastructure

Reviewed-By: Peter Rotich <peter@osticket.com>

If a plugin refuses to be uninstalled, allow it to set an error to be
displayed on the management page.

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

Authentication backends revisited

Sorta-Reviewed-By: Jared Hancock <jared@osticket.com>

This allows SSO backends to ingore authenticate method

No need to execute signal connect for each request!

SSO was originally used for a SSO plugin. The backend has since been
refactored to support other authentication backends.

Reafactor logOut to use the piggyback on auth backend

The concept of extid is being retired to pave-way for customizatable ticket
numbers.

 - This is necessary so we'll have a name on record - even on user deletion.

Pass the user id (uid) to ticket create instead of unpacked data.

Make sure new message notice goes to the user who posted the message not
neccessarily the ticket owner.

Using email headers try to determine the user.

With the introduction of collaborators, this is necessary so we can determine who is replying without relying on the
FROM address - which can be easily spoofed.

Conflicts:
	include/class.cron.php

If the entry answer being updated does not affect the ticket details form
(with type=T), then the updates do not need to be applied to the
ticket__cdata table.

Several database performance tweaks

Reviewed-By: Peter Rotich <peter@osticket.com>

This is instead of optimizing the lock table for every cron run, which
wastes a lot of db server io

And deadband session token updates to 1 per 30 seconds

Long term 'asVar' will be replaced with __toString function