Adding tracing to CycleDetectionCheckResolver

[willvedd]

Description

Adding tracing to the CycleDetectionCheckResolver because we forgot to add it during its recent introduction into the codebase. This tracing provides important insight into the graph traversal algorithm during check resolution. Similar tracing is already implemented on the LocalChecker and CachedCheckResolver (see: #1331).

References

Original PR: #1375
Similar PR: #1331

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

[jon-whit]

nit (non-blocking) - @willvedd should we add a test for this? WDYT?

// cycle_check_resolver_test.go

func TestResolveCheck_SpanCreation(t *testing.T) {
    	exporter := tracetest.NewInMemoryExporter()
	processor := trace.NewSimpleSpanProcessor(exporter)
	provider := trace.NewTracerProvider(
		trace.WithSampler(trace.AlwaysSample()),
		trace.WithSpanProcessor(processor),
	)

	otel.SetTracerProvider(provider)
	
	var cycleDetectionCheckResolver CheckResolver

        cycleDetectionCheckResolver.ResolveCheck(...)

        spans := exporter.GetSpans()
        for _, span := range spans {
            // ensure the CycleDetectionCheckResolver#ResolveCheck span is in the slice
        }

        ...
}

[willvedd]

Re: a test for the spans, I think its too heavy-handed for what's being added. There isn't precedent for it anyway.

The whole intent of this PR is to bring consistency and observability to all our resolvers. This is something we forgot to do when we introduced the CycleDetectionCheckResolver.