Implement Fitbit subscription API

[blootsvoets]

Right now, the only way to ensure that all Fitbit data of a user is present up to the current date is by resetting a user. If we implement the Fitbit subscription API, the probability of missing data would be decreased a lot, since Fitbit will inform us if something in history changes. Since the Fitbit connector itself will not always run it should be a separate always-on component that acts as a queue for the Fitbit messages. For example, we could use a simple Jersey web app with a Redis backend.

[yatharthranjan]

Do you think the RADAR-PushEndpoint would be the appropriate place for this? It has the same usecase as this and It already uses redis to store offsets for garmin backfill requests which can be reused for fitbit.

[SrividyaTR]

@blootsvoets This was also the recommendation from fitbit support. I include here the recommendation from fitbit support. "The Subscriptions API would be an ideal solution for your use case. By using a webhook notifications to be alerted of when new data is available, your application can extract the data near real time. If the Fitbit user decides to manually update their sleep log after you've already pulled the data, you'll receive another webhook notification letting you know that the data changed. Thats when your application calls the sleep API again to see what data changed"