*: switch back to gogoproto, rm stringlabels

[GiedriusS]

I suggest changing course back to gogoproto. It seems to me right now that the best course of action is to focus on implementing a new RPC protocol that has zero-copy and would give us tight control of allocations/memory usage. Here are some of the reasons why I think we should do that:

• protoc-gen-go forces []*T instead of []T. This makes sense from proto perspective but it's bad for us because it means a lot of extra allocations: not just for the data itself but also for pointers to each variable.
• protoc-gen-go forces creation of extra fields for protobuf features that we don't need: https://github.com/protocolbuffers/protobuf-go/blob/03df6c145d9653d4607107dbb3168d05a9b769c8/cmd/protoc-gen-go/internal_gengo/main.go#L370-L396. We could workaround this by custom coding marshaling/unmarshaling functions but that just feels like fighting against the RPC layer/framework.
• String labels are bad for us because they force another allocation. If we reuse the same Name/Value string format, then we can cast with zero copies, but if labels.Labels is different, then we would be forced to allocate again to accommodate the custom layout.
• grpc-go is bad for us because sending a message there happens at some unspecified time in the future and hence it is impossible to reuse memory when one Querier is connected to another Querier
• I have found that there is some speed regression with the v2 encoding; just reverting back to an older version gave me a non-trivial speed up. Didn't have time to dig into it more.

[fpetkovski]

I don’t know if we should revert stringlabels altogether. It is very useful for receivers which are very memory-heavy.

Maybe be want stringlabels specific implementations for ZLabelsToPromLabels and ZLabelsFromPromLabels using the same build tag that prometheus uses?

[GiedriusS]

I don’t know if we should revert stringlabels altogether. It is very useful for receivers which are very memory-heavy.

Maybe be want stringlabels specific implementations for ZLabelsToPromLabels and ZLabelsFromPromLabels using the same build tag that prometheus uses?

👍 I think let's distribute two versions of Thanos so that users could run Receive with stringlabels. It's awkward but should still be helpful. I'll do that in a separate PR.