Generate Go code

[tigrannajaryan]

1. Added makefile to generate code for Go and Java.
2. Remove no longer needed java_build.sh, now that makefile
   contains all that functionality.
3. Run make gen-go to generate Go code.

This allows generated Go code to be imported and used elsewhere,
particularly in OpenTelemetry Collector.

[tigrannajaryan]

@open-telemetry/specs-approvers please review.

[SergeyKanzhelev]

Please update README.md with information about this Go module that can be consumed

[SergeyKanzhelev]

LGTM giving I have limited experience with Go protos. I think it's a good idea to generate Go files right from this repository

[bogdandrutu]

I think we decided to go with a different model. Every repo that needs the proto uses got submodules and generates their own code there. What do you think about that?

[tigrannajaryan]

I think we decided to go with a different model. Every repo that needs the proto uses got submodules and generates their own code there. What do you think about that?

The OpenCensus model we used seems to be working fine. I didn't see much downsides to that. In any case if any repo wants to generate their own code they are free to do it. I think generating the code here does not prevent that.

Are there any downsides of generating the code here?

The benefit I see is that it is much easier to begin using OTLP, we lower the barrier to adoption.

[tigrannajaryan]

@bogdandrutu any thoughts on this? This is blocking Collector work that I don't want to delay that because the longer we delay the more components will need to be re-written after we adopt OTLP.
If you see any downsides to having generated code living here I am fine with generating in Collector.

[SergeyKanzhelev]

@bogdandrutu I think Go generation is fine in general. Just to simplify things for now since schema is essential for collector. I would also be against having all other languages here.

[bogdandrutu]

The feedback I got about this was from @yurishkuro who suggested that it is better because this way every repo controls their protoc compiler version etc.

I don't want to block and I think it is easy to move if we decide to do that (just a path change in the go files). So I am ok to submit this here for the moment.

[bogdandrutu]

@tigrannajaryan I would probably suggest to use vanity urls for the proto and maybe use something like:
go.opentelemetry.io/proto ?

[yurishkuro]

I'm not a fan of vanity urls, they have been known to have hiccups, even on highly popular domains.

@tigrannajaryan why can't this be simply generated in the collector repository?

[yurishkuro]

I'm fine to merge to unblock other work, but I think an IDL repo should only contain IDL. Otherwise it becomes multi-language monorepo with all kinds of resulting issues.

[tigrannajaryan]

I am happy to go with an alternate approach.

If we don't want the generated code to be in this IDL repo then where should it live? Is it in the language libraries? Or a completely separate repo just for generated code for a particular language?

If we want to do a vanity URL I will need some help with that since I don't know how to publish at go.opentelemetry.io (I assume this needs to serve the meta tag to point to wherever the package is stored).

why can't this be simply generated in the collector repository?

I think it can but will still require a vanity URL, won't it? Or we simply use github.com/open-telemetry/opentelemetry-collector/ as URL prefix?

[yurishkuro]

The idea is that the generated code is just for the repo that generates it. It does not need a public url because it should not be shared. It can be under internal/proto-gen/.