Clean up stale IDs

[notwaldorf]

Most of the IDs in the database are stale (right now I checked and about 800/1200 are not registered anymore). We should figure this out in /get_subscription_count somehow. GCM seems to have a dry_run option that you can pass to the request (https://developers.google.com/cloud-messaging/http-server-ref#send-downstream)-- maybe this won't blow up the rate limit?

/cc @philnash to see if he has any ideas

[philnash]

Wow, I need to take a look back at all this again. Does the subscription change method not receive people cancelling their subs?

I would be interested in the response from GCM regarding registration IDs that are no longer valid. And compare to the Mozilla version too (which doesn't have batching, so might be easier). I've got a long weekend coming up (yay Easter) will roll my sleeves up and try to get some stuff done here.

[notwaldorf]

I think it doesn't catch subscriptions that were cancelled outside of the site (me removing the permissions from chrome settings directly), which tbh is exactly how I turned off the notifications :)

I thiiiink that if I make each request individually to GCM (I.e not batched), then you get a legit response about the status of that registration ID. If you make a batched request then you get garbage (you get an entry for each registration ID, but not the ID itself. Maybe they're in the same order that you sent them in?)

[philnash]

It'd be reaaaally awesome if the browser would send the pushsubscription change event to the Service Worker when someone unsubscribed by removing permissions like that. Can't see in the docs if it's supposed to, so will have to test...

Also, that looks to be an event that platinum-push-messaging should possible handle too...?