Add arity key on field data returned by jsonapi

gaëlg → made their first commit to this issue’s fork.

gaëlg → changed the visibility of the branch 3275497-add-arity-key to hidden.

I need to fix related tests.

The MR adds the arity key to every resource even if not necessary (for example on responses containing a single resource).
It keeps the code simple and more predictable, but it means a lot of tests had to be updated.

Left comments/questions in MR.

I answered the questions.
If this needs fixing, we should probably fix it in JsonApiResource as well?

All the tests having to be updated to pass makes me think we are introducing a breaking change

Kinda depends, adding a meta to add responses does mean we are doing a change. Is it breaking? If your client support jsonapi it shouldn't be, its part of the spec.

So i lean towards not breaking.

Can we add an example where it’s not passed to make sure both ways are covered?

It's late. Is this also for creating entities? If so, then it should also work without, otherwise it is indeed a BC break since you might not do that :x

Not sure correct status but just thinking if we can add an example mentioned in #18

The MR only adds the arity key to read responses, it does not change the requirements for creating/editing entities.
I did not change the tests for these operations so if they pass it probably means it still works without an arity key.
(However we could have a followup to allow specifying arity when editing a reference field with duplicates, in order to specify which of the references we want to change.)

I'm not sure it is a breaking change. If your client does not use the arity key, it will continue to work as before.
The main change is that now a response can contain the same entity multiple times.

I agree that changing all these tests does not feel optimal. An alternative solution would be to only add the arity key when the response contains the same entity multiple times but it might make the code more complex and less predictable for a small benefit.