feat(api): add endpoint for user's Want to Play Games list

[ioslife]

Trying my hand at adding an endpoint for getting a user's backlog/want to play list.

This is a draft, would like to get Wes' opinion on if I am going down the right road before I get any further into this.

[ioslife]

Helpers are being deprecated, so going to go a different route.

[wescopeland]

My summarized feedback, just for public visibility:

• We're in the process of deprecating all helpers, so let's not add a new one.
• We should either reuse (or add reusable) model attributes, or keep the logic strictly in-line within the API endpoint file itself.
• The endpoint needs to be comprehensively tested and documented, both here in RAWeb and in api-docs.
• There is a user in prod who apparently has over 8000 games on their want to play list -- we should likely paginate this endpoint.
• We can't review PRs that are untested - please do not rely on CI alone to verify the code. Verify locally before the code hits CI.

[ioslife]

api-docs PR: RetroAchievements/api-docs#52

[ioslife]

the phpunit step failed for something I haven't touched and haven't seen fail before. Is this something I need to fix for this PR?

[wescopeland]

Would this be achieved by checking username vs supplied API key?

This sounds like authorization to me, which leads me to believe it should be achieved via an ability in a UserGameListEntryPolicy. There may be some nuance here as the model supports three different types of lists (see UserGameListType -- this should probably be renamed to UserGameListEntryType).

The only thing I'd like to challenge with this is maybe allowing users that follow each other the ability to see each other's list.
i.e. if I follow wes on the site and wes follows me, we could both see each other's list.

I think I'd be fine with this as long as the authorization is enforced solely by the policy mentioned above.

[ioslife]

Would this be achieved by checking username vs supplied API key?

This sounds like authorization to me, which leads me to believe it should be achieved via an ability in a UserGameListEntryPolicy. There may be some nuance here as the model supports three different types of lists (see UserGameListType -- this should probably be renamed to UserGameListEntryType).

The only thing I'd like to challenge with this is maybe allowing users that follow each other the ability to see each other's list.
i.e. if I follow wes on the site and wes follows me, we could both see each other's list.

I think I'd be fine with this as long as the authorization is enforced solely by the policy mentioned above.

I'll have to look more into policies as that is definitely out of my realm of knowledge.

This puts this PR on hold along with my PR for GetComments #2552

If anyone has some recommended reading for how to go about this, or would be interested in pairing with me to walk through how these work, let me know.

Dismissing as latest feedback is worked through

[ioslife]

I got the policy and friend relationship working as expected. There is probably some optimization that can be done, but will get to that later.

I am trying to get the tests to work as expected, but using this->actingAs($user) is not respecting using the call as $user.

[ioslife]

Resolved the issue with actingAs($user) by no longer using BootstrapApiV1 for setup. This was automatically setting a user as the one to use the webAPIKey which caused issues with how we were setting the user.

[ioslife]

@Jamiras based on your feedback I have added a policy for only allowing users to see their own want to play list, with one exception. If two users are have a mutual following relationship (are friends), they are allowed to see the list.

[wescopeland]

I only see one other thing in the current implementation that is worth commenting on. I'll do a final round of functional testing later tonight or tomorrow evening.