Support multiple tuple files in tests

[xtsee]

Scope
Allowing multiple tuple files gives you the option to break up your fixtures data (tuples) and reuse them across different tests. For example, you might have a set of tuples that contain all companies and another set of tuples for teams. This should make managing the test data a lot easier.

Example

tests: # required
  - name: test-1
    # tuple_file: ./tuples.yaml # tuples that would apply per test
    # tuple_file: # or multiple
    #   - ./tuples-1.yaml
    #   - ./tuples-2.yaml

[rclayton-godaddy]

Bump on this use case. I have a set of initial tuples to set up global relationships between models. I want to source the initial tuples as an external file and then supply the test tuples in the YAML.

Update - looking through the source code, I found out you can add tuple_files directly on the test. These will be merged with the tuples at the root of the test file:

name: Auditor
model_file: './model.fga'
tuples:
  - user: employee:sbird
    relation: member
    object: auditor:global
  - user: employee:mrapinoe
    relation: member
    object: admin:global
  - user: admin:global#member
    relation: owner
    object: namespace:foo
  - user: auditor:global#member
    relation: observer
    object: namespace:foo
tests:
  - name: "direct relation to auditor:global"
    tuple_file: './initial_tuples.json'
    check:
    - user: employee:sbird
      object: auditor:global
      assertions:
        member: true
  - name: "admin is an auditor"
    tuple_file: './initial_tuples.json'
    check:
    - user: employee:mrapinoe
      object: auditor:global
      assertions:
        member: true
  - name: "global auditor is a workflow observer"
    tuple_file: './initial_tuples.json'
    check:
    - user: employee:sbird
      object: namespace:foo
      assertions:
        observer: true

[SoulPancake]

@rhamzeh Initially, I also had a dedup logic for the tuples, but after a discussion with @aaguiarz #506 (comment)
I removed the dedup logic, we can introduce it again if that's what we want
However, do we have a dedup logic work for loading tuples? Ideally, we should dedup for all or for none.
What do you think?

[rhamzeh]

No worries, removing for now is the right choice as we think about best ways to handle duplication I think.

I'm not sure there's a clear answer, we still need to ideate on the best way to strike a balance between performance with those with a lot of tuples, complexity for those with complex store files, dx for the majority of the users and maintainability for us.

Splitting that out would be good otherwise we would be debating and not merging this PR until we figure out a way to reaxh perfection 😂

Your PR brings a lot of benefits as is already - thank you!