Add exhaustiveness checks on our "sum types".

[AlekSi]

One of the major pain points mentioned by @dexterHD recently was that we don't have a linter for problems like that. Those problems are also not obvious during code reviews. Now they are.

Previously, I tried to use https://github.com/haya14busa/gosum, but it did not really work. Last week I found https://github.com/BurntSushi/go-sumtype. It covers some of our problems and does not have false positives, so that should be an improvement. Please read its README to understand how it works.

While working on it, I also simplified some code in pmm-agent and pmm-managed to use new interfaces. For example, instead of

SendResponse(&agentpb.AgentMessage{
    Id: serverMessage.Id,
    Payload: &agentpb.AgentMessage_Pong{
        Pong: &agentpb.Pong{
            CurrentTime: ptypes.TimestampNow(),
        },
    },
})

we now write

SendResponse(&channel.Response{
    ID:      req.ID,
    Payload: &agentpb.Pong{
        CurrentTime: ptypes.TimestampNow(),
    },
})

[idexter]

Ok. First of all, I agree, it can help us in this case, but generally, I think it only masks the problem and here is why...

First, I have been reviewing a PR in our API tests today and here is some note related to this(I think).
How can it help us in cases like that? I think it can't':
https://github.com/Percona-Lab/pmm-api-tests/pull/14/files#diff-6ae141e7c42b05fc16016e87d74ad29cR113
Also, we have a good comment which implicitly describes the real problem:
https://github.com/Percona-Lab/pmm-api-tests/pull/14/files#diff-01127be9ed6b6352616a2f1c10bc3540R45

Next, I think we are adding one more problem. With this library, we are introducing a new concept which doesn't exist in Golang. The concept is "sum-type". Then, we are using it implicitly, not because we need it but because we want to solve another problem (It's like use Generics or something like this, to solve indirect problems).

Last, I think basically the problem is much deeper.
The reason we have this strange "switch/case" statements it's because of the wrong abstractions chosen.
What is an "Agent" itself? As our docs say:

"An Agent represents something that runs on the Node which is not useful itself but instead provides insights".

So it is "generalized" abstraction. The common and most important property here is "insights", and when we are using "generalization", we remove all different properties and leave abstract common ones (But we don't do this in fact. Why?).

In fact, we are using this generalized abstraction for things with different meanings and properties and we are using it in different contexts where differences more important than abstraction itself.
I think all interfaces like that are wrong.

From my POV this is our real problem. If differences are important, we can't generalize an object in one abstraction (it controversial with nature of generalization), we should use concrete type and different API endpoint for each one. But if we are using generalized abstractions and methods like "Get" or "List", we should return only common properties of our abstract "Agent" or something else.

[AlekSi]

Merging it now to unblock other work. @dexterHD, will try to explain things tomorrow.