Support pointers in un/marshal functions

[lwc]

Background

When updating protobuf to new v2 API we started to see a bunch of linting errors like:

web/graph/types/timestamp.go:13:25: MarshalTimestamp passes lock by value: 
google.golang.org/protobuf/types/known/timestamppb.Timestamp 
contains google.golang.org/protobuf/internal/impl.MessageState 
contains sync.Mutex

We use custom scalars for third party types to bind protobuf timestamps, upon updating the un/marshal functions to act on pointers, I ran into the issue outlined in #1259.

Currently gqlgen assumes that all concrete binding can happen against value types and pointers will delegate through to the underlying value type.

This PR

Updates binding code to bind to support binding to pointers directly, supporting binding between pointers and values in both directions.

Fixes: #1259

I have:

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

[coveralls]

Coverage decreased (-0.2%) to 66.267% when pulling bef9c8b on direct-pointer-binding into 39a12e0 on master.

[lwc]

This branch has been running 99designs production workloads without issue so I'm inclined to merge it.

[vektah]

It also removes a special case for binding to named types that wrap strings. This special case existed for a long since removed approach to supporting graphql enums, and the interaction between Target and CastType was proving too hard to reason about.

I hate to break it to you but I think this is going to break the prisma guys, judging from the issue that came up last time I tried to remove it 😂

[lwc]

I hate to break it to you but I think this is going to break the prisma guys, judging from the issue that came up last time I tried to remove it 😂

Bummer 😅

Oh well, after cleaning up my codegen changes it was easy enough to re-instate (I think)

[vektah]

Could we leave a comment that tries to explain the difference between Go and Type?

The target is the type of the physical field in the struct, and GO is the derived type when you combine it with the pointeryness required by the ast?

[lwc]

Done - it's not even that, it's the difference between how to bind to the type, and how to traverse to the type from a field on another type, where sometimes that is due to gql AST requirements.

I wonder if there's an abstraction that represents both pointer juggling and casting sorta like “x is satisfiable by y if i do a, b and c” 🤔

[vektah]

👍 I wonder if this needs a link to the issue, so that we dont almost delete it again

[lwc]

Done. TBH I'd still like to remove this case before 1.0.

[vektah]

Suh-weet.

The generated code looks saner. Little more in the template, but it's pretty mechanical now.