Avoid the use of deprecated MariaDB "zero dates" globally. If they're present
as attribute defaults somewhere, they will be replaced with NULL implicitly.
The existing "zero dates" in MariaDB storage will be left intact and this
should not present any issues.
The "timestamp" type in table definitions now corresponds to DATETIME in
MariaDB with "DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP", which
should be close enough to the original behaviour for compatibility purposes.
It is now the recommended type for "modified" attributes, because of the
update trigger on MariaDB. But there is no such trigger implemented on
PostgreSQL as of this moment.
The parent class for our database objects, Managed_DataObject, has a
dynamically assigned class in staticGet which objects get put into,
leaving us with less code to do the same thing.
We will probably have to move away from the DB_DataObject 'staticGet'
call as it is nowadays deprecated.
This change escapes a parameter in Local_group::setNickname(). Review
of the code paths that call this function sanitize the parameter
higher up the stack, but it's escaped here to prevent mistakes later.
Note that nickname parameters are normally alphanum strings, so
there's not much danger in double-escaping them.
We add a local_group table to store data about local groups. It has
the unique key for nickname, so /group/<nickname> looks up here.
Updated DB data object classes and data files.
