Use MariaDB event scheduler on coredb slaves.

The first jobs monitor, log, and potentially kill:

1. slow wikiuser queries running over 300s
2. sleeping wikiuser uncommitted transactions over 300s
3. unsustainable max_connections traffic spikes over 10s

They shall not touch wikiadmin, root, system users, or anything
running legitimate slow queries (dumps, etc), plus they shall be
conservative by default. 300s is an initial starting bar so that
we tread softly; it should realistically be dropped to 60s or
less. #3 is the biggest stick and only likely to come into play
during an outage.

The functionality has previously been a combination of pt-kill and
custom scripts, or Opsen responding during an outage with manual
KILL carnage. Those options all rely on a server being accessible
for one or more new connections during an outage, and that the
reserved mysqld SUPER connection slot is not in use or blocked.

Using the built-in event scheduler:

- Removes the need for separate cron jobs or polling services
- Improves the chances of an overloaded box recovering itself
- Reduces system load, network activity, use-of-perl, etc
- Is cool :-)

Change-Id: I8546406267887b073a81e713aa3dd38afce9c849