added a global try..catch stmt around UpdateWorker.run

also: let errors bubble up from pushTriggeredUpdate
The goal here is to reschedule an update if the task is still marked IN_PROGRESS. If status is not IN_PROGRESS, we do nothing but log the error with a descriptive message and stacktrace.
This logic is further enclosed in a try..catch statement as not being able to execute this code will likely be the source of "zombie thread"
ease out on locking when cleaning up stale data

1/ the batch cleanups now happen in a transaction-per-facet way which should considerably reduce locking
2/ we are using plain jdbc with a custom transaction isolation level (READ_UNCOMMITTED) for the bulk facet cleanups (facets that don't have @OneToMany et al relationships) which should further reduce locking
3/ as a result of 2/, the cleanup methods are now in an ad hoc service (ApiDataCleanupService)
reproducible test case for the setApiKeyAttribute StaleDataException bug

Note: you will need the Charles debugging proxy
Bug reproduction steps:
1) curl -v --proxy http://localhost:8899 -u username:password -X GET http://localhost:8080/test/setAtt
2) in Charles, right-click on the setAtt item in either Structure or Sequence and select Repeat Advanced...; enter e.g. Iterations: 1, Concurrency 5
concurrent ApiKey attributes modifications fix

This is a fix to a long standing bug where we would end up seeing stack traces containing:
org.hibernate.StaleStateException: Batch update returned unexpected row count from update [0]; actual row count: 0; expected: 1
In particular, this bug was triggered when an updater would try to update its time bounds (AbstractUpdater.updateTimeBounds()) and multiple threads would try to access a connector's ApiKey at once (when updating multiple ObjectTypes in parallel)
Merge branch 'wip/update-row-count-fix' into hotfix/zombie-threads-fix
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
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
Revert "fixed connector status reporting bugs"

This reverts commit bd5fcb2566a87fe7781475d61d598033c6629297.

Conflicts:
	fluxtream-connectors/src/main/java/org/fluxtream/connectors/moves/MovesUpdater.java
	fluxtream-connectors/src/main/java/org/fluxtream/connectors/twitter/TwitterFeedUpdater.java
Merge branch 'wip/updater-fixes' into hotfix/zombie-threads-fix
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]