Modified the user overview page of the admin interface to use apiKey status instead of existence of audit strings to show connector status
Modified SignpostOAuthHelper to raise an UnexpectedResponseCodeException when it gets a response other than 200 in order to be able to retrieve the HTTP response code in higher levels of the call stack.  Used this to detect and throw over rate limit exception in Fitbit updater.  Modified UpdateWorker to handle setApiKeyStatus in additional functions called by handleUpdateResult, including setting STATUS_OVER_RATE_LIMIT for result HAS_REACHED_RATE_LIMIT.  Added new result type ResultType and handling in handleUpdateResult to setApiKeyStatus to STATUS_PERMANENT_FAILURE in that case, though nothing yet generates that result.  I plan to add a new exception type which can express permanent failure when appropriate, but haven't done so yet.  Noticed problem with Fitbit update logic which may be exacerbated by adding the UnexpectedResponseCodeException throws, but haven't fixed it yet.  Need to assess impact of that on other updaters as well.
Merge branch 'development' of https://github.com/fluxtream/fluxtream-app into upstream_development
Removed MetadataServiceImplTest.java as it was based on outdated assumptions.
Merge branch 'development' of https://github.com/fluxtream/fluxtream-app into upstream_development
Added null check in addItemToMap to prevent crashes.  Not sure why this is happening, or if putting in that check will prevent items from being marked on the map, but it seems to help with the crashing for now.
Fixed setting of status ApiKey.Status.STATUS_OVER_RATE_LIMIT.  The problem was that longReschedule set status to transient failure and that had been overriding the over rate limit value.
Merge branch 'development' of https://github.com/fluxtream/fluxtream-app into upstream_development
Modified QuantifiedMindUpdater to do incremental updates properly (I hope).
Modified Fitbit updater to do tracker updates differently and to temporarily skip doing weight updates.  The tracker previously tried to update dates between a lastSyncDate stored in key attributes and today and then stored the date of the last tracker update returned by the server for where to start next time, which it only updated the stored into lastSyncDate if the update completed flawlessly.  Unfortunately it usually did not due to rate limits, which meant that in practice it kept trying to update starting from the stored lastSyncDate over and over again.  This change makes it so the tracker only updates between the stored lastSyncDate and the last tracker update returned by the server (instead of today) and updates lastSyncDate each time it successfully updates a day ending before the last server sync date, then stores the last server sync date when it gets to the end.  This should reduce duplicate server requests and give more appropriate behavior.  It also decouples the dates to update the tracker from the dates to update the scale, but does not currently enable scale updates.  That is still TBD.
Modified how audit trails are set on duplicate FAILED entries in the UpdateWorkerTask table so that they contain the trail of the error that happened rather than a copy of the parent task's trail prior to the error.  Also added stack traces in the case of rate limit exceptions.