Added getNamedNotification call to support checking for whether or not to put an update succeeded message at the end of a successful update.
Added getNamedNotification call to support checking for whether or not to put an update succeeded message at the end of a successful update.
Added getScheduledUpdateWorkerTasksForConnectorNameBeforeTime to support moves updaters rescheduling other moves update tasks that would otherwise try to run when out of quota.
Modified handling of what happens when the updater notices an old-style withings connector to mark the connector as permanently failed.
Removed special case for disableTokenSwap since refreshing google calendar tokens independently on both the main server and a mirrored instance seems to work just fine
Restructured upgradeToken to allow setting name of the message when token reauth fails to the standard status message name.
Major changes to MovesUpdater to account for quota information in headers to try to cause fewer 429s and use quota more effectively.
Modified pastDaysToUpdatePlaces temporarily down to 1, experimented with setting updateDateKeyName differently to not repeat dates on retry, but couldn't figure out how to do that in a way that doesn't risk failing to update final dates.  In the end the old algorithm was used but comments were added.
More efforts to handle stored start time to achieve the desired result.  The failure mode with the last attempt was an account where the registration date was in 2004 and it was hitting rate limit before it ever found a date with data.  Now it records the date it's about to try before it tries it, then in the case where there are any dates with data, either in the DB or from the data fetched within the loop, it overwrites the date with the max date with data.  It does that in the finally clause as well as after the normal end-of-loop.  This writes the attribute more than it probably needs to, but should hopefully work.
Try again to set start date.  The pathological case this time is big gaps either in the middle or at the end of the data.  Change to only store maxDateWithData upon successful completion of the full update, and limit to go back no more than 7 days.  This will not do the right thing in the case that a user was using the app but not on the net for > 7 days, but it's better than forever updating months or years of empty data.
Modified bulk moves rescheduling to space by 2 mins rather than 3 mins
merged with development