Iterating over Liked private likes filters

[aaronjae22]

The liked collection was keeping only public Likes even though the endpoint already requires a portability token bound to the account. The filter was only doing one thing which was hiding an account's own private and followers-only Likes from that account's own token. Those Likes never reach the destination and nothing tells the user.

Alice has one public, one followers-only and one private Like, and fetches her liked collection with her own token and it was receivingliked totalItems = 1 of 3

LOLA §6.4 expects the source to provide the liked collection to the migration token "No changes should need to be made", and we were dropping data without warning anyone so this is a change on it.

The content collection and the outbox both give a bound token every visibility, the liked collection was the only one that didn't.

There's a second little isue. Signup provisioning made every Like public because of this filter. So a new account never had a non-public Like.

Current

• liked_collection filters visibility="public" beneath the strict scope gate
• Provisioning creates 6 Likes, all public

⠀After this PR

• The filter is gone and now the owner's token gets every Like the owner made
• Provisioning creates Likes through public, followers-only and private, as it already does for Notes

Alice:            liked totalItems = 3 of 3
Provisioned actor: Like rows {public: 2, followers-only: 2, private: 2}
                   liked collection, owner's token: 6
                   Likes in the anonymous outbox:   2   (it still shows public Likes only)

[lisad]

A cool option for this idiom is to have the function or object own a couple cycles. From python 'itertools.cycle'

visibilities = cycle(VISIBILITIES)

for i in range(NOTE_COUNT):
...
visibility = next(visibility)
...

[aaronjae22]

I agree, that would be much cleaner. I'll do it in the follow up PR