Clarify OTLP/JSON behavior when receiving unknown message fields (not enum fields)

[bogdandrutu]

Usually protobuf tries to preserve the unknown fields, and works ok if we have otlp/proto (http/grpc) receiver -> otlp/proto (http/proto) exporter, aka passthrough mode. This works by keeping the bytes received untouched and put them back on the wire.

When converting between two different encodings OTLP/JSON to OTLP/Proto, or OTLP/Proto to Jaeger these fields cannot be converted.

Question is, what should we do when receiving unknown fields:

1. Fail to decode and reject the entire message? This is the default behavior of jsonpb (JSON protobuf) decoder, probably too aggressive.
2. Drop the data to ensure consistent behavior independent of the "export" encoding, to ensure that this does not work even in the case of passthrough mode (consistent with other modes).
3. Keep the data, works okish for protobuf encoding (especially if data stored or passed around as protobuf), but does not really work well for JSON, or if try to store/pass as proto after.

[tigrannajaryan]

I believe that in the spirit of our interoperability approach we should go with option 2. This allows adding new fields in the future and such fields should be ignored by receivers who don't know about the new fields.

Option 3 is a possible option for services that need to passthrough the data (such as Otel Collector). However, I do not think we need to make this part of the OTLP spec. It is a specialized application and does not need to be in the spec.