Introduce pending state for unresolved follows

[bfollington]

Builds on #647 because I already threaded app into the profile view there.

• Pull to refresh should dispatch .syncAll on app
• Follow user form is not being reset between usages
• Track which petnames are in-flight
  • Render this as an icon on the card
• Stop waiting if petname is removed from addressbook (check getPetname before resolvePetname)
• Move pending state into AddressBookService, provide a method to query the status and do that check when refreshing the profile

Demo

Screen.Recording.2023-05-16.at.5.46.10.pm.mov

Fixes #555
Fixes #492

Related to #604

[bfollington]

Ensure everything is refreshed if a user is trying to manually refresh their following list.

[gordonbrander]

Another way we do this is through the slightly more compact/fancy approach of:

.onReceive(
    store.actions.compactMap(AppAction.from),
    perform: app.send
)

where AppAction.from is an extension that creates an app action from a local action, or else nil. The advantage being that the AppAction.from extension can be tested.

Non-blocking.

[bfollington]

Clean! I like that this moves the mapping nearer to the model and away from the view.

[bfollington]

@gordonbrander not related to this work but I think I'll disable the swiftlint github check, it just adds too much noise to the PR review. I'm using it in Xcode locally so I might update #573 to remove the github action as well.

[gordonbrander]

LGTM with a couple questions

[gordonbrander]

Another way we do this is through the slightly more compact/fancy approach of:

.onReceive(
    store.actions.compactMap(AppAction.from),
    perform: app.send
)

where AppAction.from is an extension that creates an app action from a local action, or else nil. The advantage being that the AppAction.from extension can be tested.

Non-blocking.

[gordonbrander]

Preference for this no-op to belong to the update function, rather than the view. When actions handle their own no-op based on model state, it's more easily testable. It also makes sending the action foolproof.

Non-blocking.

[bfollington]

I introduced a new action requestNavigateToProfile which can result in pushDetail if resolved or failPushDetail if not. This logs a debug message and does nothing else atm.

[gordonbrander]

Open question, but would it be better to have this retry with backoff logic be part of an update function instead? (If fx fails, send another after a growing delay).

The advantage would be that retry would be forced to fold with app state at each step. The actions would be sent through the logs, and current backoff value would be written to the model where we can inspect it.

Non-blocking.

[bfollington]

I can see the value of this but it could be a little over-complicated right now.

The main issue I see is that multiple of these processes can be running at once (rapidly following multiple users before the last one resolves), so tracking the state will require attaching an ID to each background job etc.

I'd like to think a bit more about the right abstraction to make it trivial for different components to sign up for this functionality and share the code, put some initial thoughts down here: #658

[gordonbrander]

Qs:

• Should this be a general enum, similar to LoadingState?
  • Is this the same semantics as LoadingState? It's ok if subtly different.
  • If different, still worth generalizing this I bet. We have a lot of places that have the same network resolution lifecycle.
• Is there a resolved success/failure? (resolved(Result))

Non-blocking.

[bfollington]

I dropped the Petname prefix and extracted the type and added a Cid payload to resolved since I currently view the definition of resolution as "take this address and give me the CID on the other end".