fixed connector status reporting bugs

A lot of connectors continue to try to update even though there are in a hopeless situation.
see https://app.asana.com/0/790107150363/15610210902750
Note: this batch of fixes only addresses correctly reporting the status of a connector update
removed screen_name from statuses API call

generates 404s for people who have changed it
use utf8mb4 for MovesPlace's name column

see https://app.asana.com/0/790107150363/15662593247635
Request the userRegistrationDate at each incremental update

The userRegistrationDate apparently gets reset which causes date bounds errors when using the original one

see https://app.asana.com/0/790107150363/15687948091041
Merge branch 'wip/connector-fixes' into wip/connector-reporting-fixes
set ApiKey reason when setting to permanent fail

ApiKey no has a reason field in order to make it easier to distinguish between updaters that have been automatically shut down due to oauth needing a reauth or because of some other condition that is deemed to be hopeless wrt to getting the updater to a healthy state again.
Several such conditions are enumerated in ApiKey's PermanentFailReason inner class:
CLIENT_ERROR: typically an http 4xx type error
SERVER_EXCEPTION: PersistenceException or exception in the org.springframework root package qualify here
MANUAL_INTERVENTION: use of the admin interface to manually set a connector to permanent fail
UNKNOWN: server complaining in a non standard way
added an admin UI page that lists permanent fail updaters
properly log thread pool vars
added PESSIMISTIC_READ LockModeType to avoid obscure retrieval failures

trying to avoid errors like:
GenericJDBCException: could not load an entity: [org.fluxtream.domain.ApiKey#xxxx]
Forcing  workerTask status to FAILED in case of unexpected exceptions
undoing this as it seems to be causing deadlocks
get the apiKey only once
abort tasks that have failed due to needing reauth

This is the "centralized" way of reporting NEEDS_REAUTH and there we didn't set the workerTask's status to FAILED like we manually did in other cases...
improved the admin UI's updater report page

- added a status column
- added a guest id form filter
- added checkboxes for filtering results by status type (up, transient- permanent- fail and over-rate-limit)
- added guestId as a second sort argument
- removed the query limit
added support for handling runkeeper token revocation
Fixed some issues with handling Runkeeper token revocation.  It should now properly handle 403s with reason=Revoked, and properly delete the connector and data when delete_health=true.
enable currently queried/selected items to be forced to update

- added checkboxes to manually select which connectors we want to update
- added API admin calls to be able to batch update connectors based on a list of apiKeyIds
- made it possible to (un)select all connectors at once
Merge branch 'wip/runkeeper-revoke-fix' into wip/connector-reporting-fixes
fixes to the reporting mechanism

- added an AUTH_REVOKED PermanentFailReason
- fixed missing incremental update code path in the admin UI
give all the debugging information we have