[FEATURE] Split hook interfaces about go-sdk HOT 3 CLOSED

I like this approach a lot, I think this resolves any of the concerns with the alternatives I had found. Thanks @james-milligan , I’ll proceed with this method

from go-sdk.

we could create an UnimplementedHook struct to be placed within any new hooks, this unimplemented hook would contain all the required, but empty, methods to satisfy the interface. A developer would then 'replace' the unimplemented methods with their own:

https://go.dev/play/p/XXcPF3ffLMS

this pattern is seen in grpc generated code and I believe will help with the reduction in breaking changes if, for example, a new method is added. Any implemented methods should still break the interface if they change

from go-sdk.

If we go ahead with this we lose any type assurances at compile time. A developer can no longer be confident that their hook will get called as anything will be accepted as a hook (and subsequently not called if it doesn't match one of the before/after/error/finally funcs).
If, for example, the hook interface gets changed down the line in a breaking change, any developers who update the sdk would know immediately that they needed to update their hooks. If, however, we've made this change they wouldn't see any compile time errors and their hooks would cease to work silently.

I'm now of mind that keeping the interface as it is provides more benefits (at the cost of forcing developers to have empty functions). Thoughts? @james-milligan @beeme1mr @toddbaert

from go-sdk.