Decide if version number is needed in *Data and *Request messages

[tigrannajaryan]

We may want to add a format/protocol version number to messages like LogsData, MetricsData, ExportLogsServiceRequest, etc.

The request is originally coming from open-telemetry/opentelemetry-specification#1957 (comment)

I would like to understand why the version number is necessary in the payload. OTLP spec claims the following:

2. For minor changes to the protocol future versions and extension of OTLP are
   encouraged to use the ability of Protobufs to evolve message schema in
   backwards compatible manner. Newer versions of OTLP may add new fields to
   messages that will be ignored by clients and servers that do not understand
   these fields. In many cases careful design of such schema changes and correct
   choice of default values for new fields is enough to ensure interoperability
   of different versions without nodes explicitly detecting that their peer node
   has different capabilities.

Adding the version number seems to contradict with this, so we need to explain why this doesn't work.

[carlosalberto]

So I think adding version is mostly a defensive strategy, as protobuf/json doesn't have some of the nice backwards-compatibility features that the binary format has, with the most obvious one being the renaming support (see protocolbuffers/protobuf#3949).

We recently decided to rename InstrumentationLibrary to InstrumentationScope, and as part of the migration process, we will keep both for some time, and will eventually remove the former - but if we had decided to go with the straightforward rename (which was seriously considered), having the version number would have helped in the JSON side.

Of course, consumers/parsers can always try to detect features and double (triple) look for existing values (e.g. if instrumentation_scope exists, use it, else fallback to instrumentation_library), but I don't consider that as a very elegant solution.

Personally I don't expect us to be renaming/changing the proto definitions (too often), but if for whatever reason we really must do it, we will be (somewhat) covered.

[carlosalberto]

Forgot to mention that during the last call we decided to not add this version field, at leas initially, and we will add it if/when it is needed, so this is not a blocker for making OTLP/JSON stable anymore.

[bogdandrutu]

Per the discussion in the SIG, we will not add initially a version.

[tigrannajaryan]

@bogdandrutu was there a new discussion that I missed or you are referring to previous discussions?

Also, there is an OTEP open that proposes to add the version number to the request headers: open-telemetry/oteps#204