Config option to only make cyclical struct fields pointers

[ianling]

This PR #701 caused all struct fields whose type is a struct to be generated as pointers. This was necessary to resolve issues with cyclical relationships between structs (e.g. StructA contains a field of type StructB and vice versa) because those will cause compiler errors.

However this was overkill and also caused non-cyclical struct relationships to turn into pointers. For example:

type StructA {
    field_one: String!
}

type StructB {
    field_one: Int!
    field_two: StructA!
}

...would unnecessarily generate StructB.field_two with the type *StructA instead of just StructA.

This PR adds a config option that allows a user to retain the pointer change from the linked PR for cyclical relationships, but otherwise gqlgen will not change the type to a pointer for cases like the example I gave above.

The default behavior of gqlgen remains the same, so this will not affect any existing users unless they add struct_fields_always_pointers: false to their config.

Examples of behavior with this PR, using struct_fields_always_pointers: false:

• Cyclical relationships generate pointers (matches current behavior)

type StructA {
    b: StructB!
}

type StructB {
    a: StructA!
}

type StructA struct {
    B *StructB
}
type StructB struct {
    A *StructA
}

• Non-cyclical relationships do not generate pointers (new behavior)

type Name {
    first: String!
    last: String!
}

type Person {
    name: Name!
    age: Int!
}

type Name struct {
    First string
    Last string
}
type Person struct {
    Name Name
    Age int
}

• Recursive structs generate pointers (matches current behavior)

type StructA {
    a: StructA!
}

type StructA struct {
    A *StructA
}

I have:

• Added tests covering the bug / feature (see testing)
• Updated any relevant documentation (see docs)

[coveralls]

Coverage increased (+0.09%) to 75.026% when pulling e15da34 on ianling:cyclical_struct_relationships into 4cdf702 on 99designs:master.

[ianling]

Need to update docs and examples, but is this change okay otherwise? @StevenACoffman

This will be a breaking change for any users of gqlgen whose schemas include non-cyclical struct fields (see my example of this above), as this change alters the generated structs in that case.

To make this less bad, we could make this behavior non-default using a config option, but I do think this should be the default behavior, as it is what a developer would expect to happen, in my opinion. That said, the slice pointer thing is also behind a config option and does not behave the way I would expect by default, so this would not be the only time where something unexpected happens that requires changing the config.

[StevenACoffman]

So this will cause a lot of churn for existing users if they don't specifically opt-in, so I'd ideally like this changed behavior to be a config option if possible.

[ianling]

I added a config option for this which defaults to gqlgen's behavior today without this PR, so that it doesn't affect any users unless they explicitly opt in to the new behavior using the config option.

I also added tests that validate the old behavior and the new behavior, and added the new config option to the config doc page. The examples did not need to be changed since the default behavior of gqlgen has not changed.

[StevenACoffman]

Can you clarify what you mean by "default to old behavior"? Before PR #701 was merged is one "old behavior", and before this PR is merged is a different "old behavior"?

[ianling]

Woops, to clarify, "old behavior" is the behavior of gqlgen today without my PR. New behavior is the behavior with this PR.  gqlgen, with my PR, will still default to the same behavior as today. The behavior will only change if you add `struct_fields_always_pointers: false` to your config. The default value for that option is `true`

[ianling]

Fixed the golangci-lint issue...