feat: add dispatch count for list objects

[poovamraj]

Description

As a continuation of adding DispatchCount metrics to the Check endpoint, we have added it to ListObjects as well to identify the amount of reverse expands and checks that are done for each request.

ListObjects works by reverse expanding from a subject to a list of objects with particular relation. There will be recursion involved in cases union and inheritance uses cases. And we run the check on each object that is retrieved if there is intersection or exclusion present so as to identify the related list of objects. We are counting these dispatches to identify the complexity of queries.

References

Continuation of Dispatch Count in Check - #1343

Review Checklist

• I have clicked on "allow edits by maintainers".
• I have added documentation for new/changed functionality in this PR or in a PR to openfga.dev [Provide a link to any relevant PRs in the references section above]
• The correct base branch is being used, if not main
• I have added tests to validate that the change in functionality is working as expected

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

❗ No coverage uploaded for pull request base (main@f27a553). Click here to learn what that means.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1427   +/-   ##
=======================================
  Coverage        ?   85.81%           
=======================================
  Files           ?       85           
  Lines           ?     7938           
  Branches        ?        0           
=======================================
  Hits            ?     6811           
  Misses          ?      793           
  Partials        ?      334           

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

[jon-whit]

@poovamraj please add some more tests, specifically these cases:

Test Case 1

model
  schema 1.1

type user

type group
  relations
    define member: [user]

• group:eng#member@user:jon
• group:fga#member@user:jon

ListObjects(group#member, user:jon)

This returns 2 dispatches - note that this is non-ideal and points out an inefficiency in our algorithm, because user is directly related to group#member and so this should be a single database lookup without any dispatch required. The only time dispatch should be required is with expansion of usersets and/or nested group/hierarchy expansion. More on this coming soon 😄 . I'm working on alternative algorithm proposals to avoid this and be more efficient.

Test Case 2

model
  schema 1.1

type user

type group
  relations
    define member: [user, group#member]

• group:eng#member@group:fga#member
• group:fga#member@user:jon

ListObjects(group#member, user:jon)

This should return 2 dispatches today - note: it should only require 1 but because of the inefficiency in our algorithm today this returns 2.

Test Case 3

model
  schema 1.1

type user

type document
  relations
    define editor: [user]
    define viewer: editor

• document:1#editor@user:jon

ListObjects(document#viewer, user:jon)

This should return 2 dispatches today - again, it should only require 1 dispatch but it won't until we improve our algorithm a bit.

[poovamraj]

@jon-whit added the test cases except No.1 as it is already the first test case

[willvedd]

Nice job.