Resource Relationship Brainstorming Notes

## Structure of the reference field

Doesn't have to be backwards-incompatible. We can make a Go type that is JSON-serializable into a `oneOf` JSONSchema validation type. We did this for a "string or list of strings" type when adding functionality to the code generator for dealing with when fields in the generator configuration could be either a string or []string: https://github.com/aws-controllers-k8s/code-generator/blob/7dd0760fcd1cc03646423fb58b1bba773c795dfb/pkg/generate/config/operation.go#L82-L98

[x] Focus of introduction on use-case
[x] Punt deletion for second revision
[x] Add an usecase example in introduction(generator.yaml for apigatewayv2 route)
[x] Scope down to same API group at the moment(main issue RBAC)
[x] Consider adding selector for future
[x] Consider slices of identifiers in current solution
[] Need to have a mechanism of preventing endless failed fetches of wrong related identifiers
[] New prom metric for time spent looking up dependent resources in k8s api
[x] maybe support slices of identifiers at the start (in the generator) BUT for this first approach only take/assume the first entry

**Union of types**:

Example of API Gateway v2 API's [Route resource](https://aws-controllers-k8s.github.io/community/reference/apigatewayv2/v1alpha1/route/), which has a required "apiID" field in it.

Using a string directly:

spec:
  apiID: "my-api-id"

Options for referencing subfield (two options):
1. Using `from`

spec:
  apiID:
    from:
      name: my-api
      # namespace: maybe

2. Using `ref`

spec:
  apiID:
    ref:
      name: my-api
      # namespace: maybe