Modules: add opentelemetry-proto module with protobuf definitions

[inge4pres]

Reason for this PR

Closes #19

Details

We add a new folder in the monorepo, hosting the module with the protobuf-generated code.
Same dependencies and buld steps are ported to the main build.zig.
A new build folder component is made for the protobuf module.

Documentation is updated to reflect the multiple modules structure.

[inge4pres]

For testing this PR you will need to sync the submodule first.

git submodule update --init opentelemetry-proto/proto-src

and then you can run the build steps

zig build proto-generate
zig build proto-test

[agagniere]

Why use a git submodule here ? we could add it as a lazy dependency in the build.zig.zon

[inge4pres]

Why use a git submodule here ? we could add it as a lazy dependency in the build.zig.zon

@agagniere good question 👍🏼
It's what has been used in the previous repo because we wanted to be able to pin it to tagged versions.

Can we do the same with lazy dependencies? I genuinely haven't used them.
Does a lazy dep require a build.zig/build.zig.zon in the remote repo?

[agagniere]

We absolutely can pin dependencies (lazy or not):

zig fetch --save=opentelemetry_proto git+https://github.com/open-telemetry/opentelemetry-proto#v1.11.0

note the --save=<name> that is mandatory when the fetched repo lacks a build.zig.zon

[jaronoff97]

Do we handle the intricacies / weirdness of OTLP json with hex encoding?

[agagniere]

@jaronoff97 are you referring to what's been addressed in this PR ?

[jaronoff97]

@agagniere not exactly, the OTLP json object's trace id should be treated as a hex (this is why otel go has a custom deserialization method) instead of a string. i have a fork of zig-protobuf to handle this case. Check the spec deviations here

[inge4pres]

the OTLP json object's trace id should be treated as a hex (this is why otel go has a custom deserialization method) instead of a string. i have a fork of zig-protobuf to handle this case. Check the spec deviations here

@jaronoff97 seems like we need a dedicated issue for this. I'll create one, but that's nothing that concerns this PR, correct?

[jaronoff97]

I don't think it should block this one, no, but it's something we should be aware of for powering the json representation off of these protos.

[inge4pres]

We absolutely can pin dependencies (lazy or not):

zig fetch --save=opentelemetry_proto git+https://github.com/open-telemetry/opentelemetry-proto#v1.11.0

note the --save=<name> that is mandatory when the fetched repo lacks a build.zig.zon

Got it thanks, so we could then avoid the submodule?
That sounds good, I'll try 👍🏼
There is the "update-tag" build step that we have to figure out how to change if we move away from submodules, I'll see if there's a way to handle that.

[inge4pres]

@agagniere the lazyDep is working but I can't force-push on this branch.
I'll create a second PR with the commit that does it after merging this one