Ability to ignore specific fields in the API

[muvaf]

Is your feature request related to a problem?
In generator.yaml, users are able to supply custom configuration that will be taken into account during the generation. When I tried using the following generator.yaml for apigatewayv2.yaml, it didn't have any effect:

ignore:
  shape_names:
    - Name

When I dug into the code, I realized that the code checks whether memberShapeRef.Shape.ShapeName appears in the ignore list or not. However, the value of that field is StringWithLengthBetween1And128. When I let it go through all the top level fields of API CRD, it appears that memberShapeRef.Shape.ShapeName could either be a known type like CorsConfiguration or just a detailed version of string like StringWithLengthBetween1And128 though it's still represented as string in the codebase. There are cases like ECR Repository where the type for RepositoryName is RepositoryName in the json file but that's just a wrap around string similar to StringWithLengthBetween1And128, it's still string in the codebase. However, since there is a differentiating layer there, we're able to target that one specific field by its type in json.

Describe the solution you'd like

What I wanted to achieve is essentially to ignore some of the fields in the API because I'd like to handle them manually. Using ignore.shape_names is sort of abusing it for a purpose it wasn't meant to but I feel like the initial purpose might be same as what I'm aiming for here, i.e. ignoring a field in a struct, rather than a type which might be string.

I thought we can be more precise if we ignored a specific field of a type. For example, CreateApiInput.Name is very specific and not tied to the type of that field. Here is an implementation of this suggestion that keeps shape_name in place, but there is some overlap in the objectives of the two. So, we might want to expand one of them to cover what we want or just keep both separated as they are in the PR.

Describe alternatives you've considered

Another alternative could be to have users give the field path relative to CRD itself. For example, instead of having to specify both CreateApiInput.Name and DeleteApiInput.Name, they can just say .Name, meaning Name field in at the top level spec struct should be ignored. If it's not top level, it could be given as CorsConfiguration.SomeField where CorsConfiguration is a type included in types.go This is kind of trickier to implement but doable.