mock: Add mockgen workflow

[positiveblue]

• make mock: generates all the mocks for testing.
• mock-check: generates all the mocks + checks if any *.go file changed.
• make gen: generates all the auto generated files (protos + mocks).
• Add mock-check to our CI

Create mocks for sidecar/interfaces.go and internal/test/interfaces.go and use them for rewriting the TestRegisterSidecar.

[guggero]

Very cool to see the gomock package in action!
I really like fact that we can generate very dynamic mocks on demand. And the way to use them also looks pretty easy to get started with.

This example use case also shows nicely why it's great to work with mocks: one can more easily test all possible branches as you demonstrated by adding two additional test cases.

IMO we should have a discussion about using gomock in lnd as well and take this PR as a base for the discussion.

[yyforyongyu]

Glad to see another mock in action!

Imo mock is a necessary component that's missing from our unit tests. It makes tests much easier and, in particular, since we have many goroutines flying around, I find it very helpful to validate whether a call does happen inside another goroutine.

As mentioned before, lnd and naut have already started using mocks (thanks to @bhandras!). The challenge I see for lnd is that it's missing interfaces, where it makes the mocking impossible. There is an ongoing effort made by @Crypt-iQ where we want to build more interfaces inside lnd's peer. And we def need more to make the mocking happen.

That being said, what's your opinion about the two tools, go/mock and testify/mock? Curious about your preference here. I chose testify/mock because we were already using testify inside lnd and from this article. Tbh I don't have that much experience using mocks inside go so that choice is more or less like, we just need A mock😂

[Crypt-iQ]

As mentioned before, lnd and naut have already started using mocks (thanks to @bhandras!). The challenge I see for lnd is that it's missing interfaces, where it makes the mocking impossible. There is an ongoing effort made by @Crypt-iQ where we want to build more interfaces inside lnd's peer. And we def need more to make the mocking happen.

When we get native fuzzing in golang, mocks will be very helpful. Since I imagine the golang fuzzer is coverage-driven, it is good to separate components and make them "dumb" to not confuse the coverage signals (e.g. so they don't spawn goroutines, have nondeterministic behavior, etc). Also if you want to run a lot of fuzzers, you don't want something like an invoiceregistry or htlcswitch in lnd on each fuzzing instance if it's just testing round-trip parsing of a particular component, so mocking helps there too.

[guggero]

LGTM, just a few nits 🎉

Sorry if I'm being extra nit-picky, but if this is going to be our template for mock-usage, things should look extra tidy because they are going to be copy/pasted a lot 😅

[yyforyongyu]

Go mock go!

[guggero]

Just waiting for @Roasbeef's opinion on using generated mocks, otherwise this is ready to be merged.