[MBL-1931] Update FetchUserSetup to include ppoHasAction in fragment

[stevestreza-ksr]

📲 What

This PR re-adds ppoHasAction to the user loading query, this time as part of FetchUserSetup. This restores the action loading as part of setup, but doesn't break logged-out users loading projects.

🤔 Why

This functionality was reverted for breaking loading projects for logged-out users in #2218.

🛠 How

First, the original disabling PR was reverted to restore the functionality. Then, I created a new fragment, PPOUserSetupFragment, which loads the ppoHasAction field. Then, the field was removed from the old query and the new fragment was added to the FetchUserSetup query.

✅ Acceptance criteria

• When the feature flag is enabled, the ppoHasAction will be reflected in the badge on the activity tab
• When logged out, tapping a project will not cause an error to appear in the "back this project" bar

[amy-at-kickstarter]

Is there a strong reason to keep ppoHasAction on AppEnvironment.current.user, instead of pulling it out like AppEnvironment.current.userHasPPOAction?

Mutating an object that was returned directly from an API request like currentUser causes me to raise an eyebrow - I don't see it causing any immediate problems, but it's a precedent that makes me nervous.

That said, the other pattern (currentUserEmail) isn't beautiful either.

[stevestreza-ksr]

At this point I think that is just a carryover from originally building this on User. I'll move it out to this pattern for now.

We'll probably want to rethink "extra user stuff that shouldn't be on User" at some point.

[amy-at-kickstarter]

Agreed!

Completely out of scope here, but "extra user stuff that shouldn't be on User" touches on two interesting pieces of tech debt:

1. Everything we've stapled on to User comes from GraphQL. Would making our session login/logout a GraphQL call with a nicely apportioned fragment solve this problem?
2. Immutable server objects are one of the annoying things preventing us from getting rid of Prelude, since we do this Project.template |> Project.lens.foo .~ bar all the time in our tests. There's an open question for what we want to do to solve that problem - do we make all our model objects mutable, or implement some other pattern like a builder (User.builder().ppoHasAction(true).email("[email protected]")...) or mock model objects for testing (MockApiObject<User> foo; foo.ppoHasAction = true)?

[stevestreza-ksr]

I think the problem for 1 is twofold, one is how we load the query now (which we do through FetchUserSetup and fragments now), and the other is the storage side on AppEnvironment (this is why we're overloading with multiple properties right now).

We did discuss a bit about immutable objects a couple months ago. One tool we have now that we didn't have before is macros, so we might be able to build something that generates builders for those.

[scottkicks]

LGTM 👍 Maybe we can discuss how we might address Amy's out of scope points in an iOS sync!