ActivityPub migration procedure

[Gargron]

Once one account is detected as going from OStatus to ActivityPub,
unsubscribe from old PuSH subscription, invalidate WebFinger cache
for other accounts from the same domain, and queue up a re-resolve
for all of them.

[Gargron]

I am a bit worried if this is the best possible code to solve this problem.

cc @unarist @ThibG

[ClearlyClaire]

I only have read the current (I've been told there have been changes to the way followers worked since) spec yet, and not your implementation. So, this is not my final opinion about this change, but so far it looks good to me, although I'm not sure remote accounts should be scheduled for re-resolving: as long as they are invalidated, they will be resolved when needed, right?

[unarist]

Some thoughts:

• Even we recognize they're activitypub_ready, they may not recognize we're activitypub_ready and they don't send ActivityPub activities to us. We should wait receiving activity from them before unsubscribe.
• FetchRemoteAccountService and ProcessAccountService may also be called directly. These cases wouldn't be handled by this patch.

[Gargron]

• Addressed @ThibG's concerns ("I'm not sure remote accounts should be scheduled for re-resolving: as long as they are invalidated, they will be resolved when needed"), this simplifies the code a fair bit
• Addressed @unarist's concerns: Moved the migration detection to ActivityPub::ProcessAccountService, which is called both from ResolveRemoteAccountService and other places; only unsubscribe from PuSH when an ActivityPub payload arrives in the inbox

[unarist]

I've forgotten about subscription expires. PuSH subscription may expire just after Account#protocol update, but we won't resubscribe them due to protocol: activitypub. It means we can't receive updates from that until first AP payload arriving.

My ideas:

• A) Update SubscribeScheduler to allow resubscribe for accounts which AP ready but not yet unsubscribed. In other words, resubscribe! if (ostatus? || !subscription_expires_at.nil?).
  (note: current master doesn't unsubscribe for upgraded accounts, so those may be fixed manually)
• B) In the upgrade process, resubscribe subscription immediately (unless it's called from AP receive handler) and send Update profile activity. This ensures enough grace period, then encourages them to upgrade protocol for our account.

BTW, Account#protocol is used as what protocol should we use to interact with them. Also many interaction services doesn't update profile, only reads Account#protocol. So delaying its update means may bit delays protocol migration. Although I don't see serious issue for that.

[Gargron]

@unarist Addressed first point - do not really understand the last one, but I think we're probably good to go here?