Import open-telemetry/opentelemetry-proto submodule and generate protobuf bindings locally

[evantorrie]

Fixes #793 and will allow opentelemetry-proto repository maintainers to remove the generated Go code from their repo.

1. OTLP .proto sources added as git submodule at internal/opentelemetry-proto.
2. Generated protobuf files committed to internal/opentelemetry-proto-gen.
3. References to Go module github.com/open-telemetry/opentelemetry-proto now changed to reference internal package go.opentelemetry.io/otel/internal/opentelemetry-proto-gen.

In normal workflow, the git submodule should not be populated. Only do so with git submodule update --init when a new version of the protobuf sources are released in the opentelemetry-proto repository and you need to force the workflow to regenerate updated Go bindings in internal/opentelemetry-proto-gen.

[lizthegrey]

What's otel-collector doing with this same problem?

[MrAlias]

@lizthegrey for backstory: open-telemetry/opentelemetry-proto#79 (comment)

and from that the collector solution: open-telemetry/opentelemetry-collector#1037
it is just a manually run command

[lizthegrey]

@lizthegrey for backstory: open-telemetry/opentelemetry-proto#79 (comment)

and from that the collector solution: open-telemetry/opentelemetry-collector#1037
it is just a manually run command

Ah, excellent, so a similar solution of checking the generated .pb.go files in subject to normal code review, but not run automatically from circleci and instead run by hand. We should consider upstreaming the Github Action so that they get the benefit of it too!

[yurishkuro]

🎉 🎉 🎉

[yurishkuro]

Recommendation: in Jaeger we have a separate CI step "check-proto" that re-runs the .pb.go file generation and verifies that checked-in version is the same as would-be-generated one. It catches issues when something in the toolchain changes, like the version of generator plugin.

[jmacd]

Thanks @evantorrie