importer/twitter: update longpoller, as user stream will soon be deprecated

[mpl]

https://blog.twitter.com/developer/en_us/topics/tools/2017/announcing-more-functionality-to-improve-customer-engagements-on-twitter.html

[mpl]

yes, it does. we're using the user stream (https://userstream.twitter.com/1.1/user.json) to do the long polling.

[mpl]

They plan to deprecate user stream on the 16th of august: https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/api-reference/user-stream

[mpl]

https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/migration/us-ss-migration-guide

[mpl]

From what i gather in https://developer.twitter.com/en/docs/accounts-and-users/subscribe-account-activity/guides/getting-started-with-webhooks users might need to have a developer or premium/enterprise account in order for their importer app to use webhooks, which is probably a no-go. But I'll keep on exploring that migration.

[mpl]

I have started on this. Some parts are doable, but in addition to the hindrance that a user would have to register a dev account, the users would also have to be aware that their Perkeep instance has a public (i.e. unauthenticated) access point, that is to say, the webhook through which twitter feeds them events. (It is also annoying to implement (adding an unauthenticated webhook to the importer), but that is irrelevant to my point.)

I don't think this is all worth doing just for the "real time updates" feature. I suppose it all boils down to the fact that our "each user their own importer (== their own twitter app)" does not match twitter's business model, where they rather expect us (perkeep.org) to run one app for all of the Perkeep users.

So I'll move on to other things unless/until someone disagrees.

@bradfitz WDYT?

[mpl]

reopening, because I suppose as part of this issue, we should now remove the longpoller code. I'll do that before closing.

[mpl]

https://perkeep-review.googlesource.com/c/perkeep/+/18546