Request meta tests boilerplate

[mrmarcosmagalhaes]

Closes #1500

QUALITY CHECKLIST

• Changes implemented in code
• Complies with our contributing guidelines
• Adapted tests
• Documentation updated

[bkoelman]

Thanks, this looks great!

I've changed the base of this PR, so that status checks run.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 90.75%. Comparing base (8c59d1b) to head (3605490).

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1746   +/-   ##
=======================================
  Coverage   90.75%   90.75%           
=======================================
  Files         468      468           
  Lines       14662    14662           
  Branches     2315     2315           
=======================================
+ Hits        13306    13307    +1     
+ Misses        920      919    -1     
  Partials      436      436           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[bkoelman]

The following endpoints are missing:

• operations: update-to-one-relationship
• operations: update-to-many-relationship
• operations: add-to-relationship
• operations: delete-from-relationship

Relationships come in two flavors: to-one (data contains an object in the request body) and to-many (data contains an array in the request body). We should have coverage for both.

Additionally, data can contain either a resource object (consisting of attributes and/or relationships), or a resource identifier object (consisting of types/ids, but no fields). See the JSON:API spec for details and examples.

Furthermore, there are additional places where meta can occur in request bodies. For example:

var document = new Document
{
    Meta = [],
    Data = new SingleOrManyData<ResourceObject>(new ResourceObject
    {
        Meta = [],
        Relationships = new Dictionary<string, RelationshipObject?>
        {
            ["some"] = new()
            {
                Meta = [],
                Data = new SingleOrManyData<ResourceIdentifierObject>(new ResourceIdentifierObject
                {
                    Meta = []
                })
            }
        }
    }),
    Operations =
    [
        new AtomicOperationObject
        {
            Meta = [],
            Data = new SingleOrManyData<ResourceObject>(new List<ResourceObject>
            {
                new()
                {
                    Meta = [],
                    Relationships = new Dictionary<string, RelationshipObject?>
                    {
                        ["some"] = new()
                        {
                            Meta = [],
                            Data = new SingleOrManyData<ResourceIdentifierObject>(new List<ResourceIdentifierObject>
                            {
                                new()
                                {
                                    Meta = []
                                }
                            })
                        }
                    }
                }
            })
        }
    ]
};

For demonstration, I've used data arrays only in operations above, but single/many can occur in all places.

Based on all the possible combinations, I don't think it makes sense to separate tests by the place where meta occurs (top-level, data, relationship, etc.). It would be easier to have a single test per endpoint/operation that contains all possible locations for that endpoint. However, because we're dealing with both to-one and to-many relationships, we'll need separate endpoints (because SupportTicket contains a to-one, whereas ProductFamily contains a to-many).

So, for example:

• Accepts_meta_in_patch_resource_request_with_to_one_relationship: PATCH /supportTickets
• Accepts_meta_in_patch_resource_request_with_to_many_relationship: PATCH /productFamilies

Oh, and relationship endpoints don't take attributes/relationships, so they should be removed from the existing tests.

[bkoelman]

This is not a post-relationship request. It is a post-resource request that includes a relationship.
A post-relationship request would look like:

POST /supportTickets/1/relationships/productFamily

{
  "data": {
    "type": "productFamilies",
    "id": "5"
  }
}