feat: add new API definitions for relation metadata & assignable types

[jon-whit]

Description

This starts the beginning of a new OpenFGA model package v2beta1 which contains the preliminary definitions for the type info in TypeDefinitions.

References

Review Checklist

• 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]

The idea here would be use to v2beta1 to support the new TypeDefinition structure and once the old structure is deprecated we can remove it strictly in favor of the v2beta1 defininitions.

If the v2beta1 definitions stick long enough for us to commit to long term maintainability, then we can cut v2beta1 under an official v2 in the future.

@rhamzeh I recognize the impact of this on SDKs and tooling, but I think it's warranted to make the model of a TypeDefinition more clear and it also supports our use case for ListObjects more accurately.

Code in the server becomes:

typedef := datastore.ReadTypeDefinition("document")
relations := typedef.GetRelations()

relation, ok := relations["viewer"]
if !ok { // relation doesn't exist }

typeinfo := relation.GetTypeInfo()

What do you think? Can we proceed with this approach?

[craigpastro]

By the way, should we bring all the proto files to v2beta1 so we don't need to have two imports everywhere?

[jon-whit]

By the way, should we bring all the proto files to v2beta1 so we don't need to have two imports everywhere?

Not all of them. If we evolve our grpc service API definitions then we can start a new openfga.v2beta1.OpenFGAService at a later date. For now I think it makes sense to have separate API definitions since they are under different packages. If we have a shared package between the two we can create a shared package instead.

[craigpastro]

LGTM

[craigpastro]

LGTM