[opentelemetry source,opentelemetry sink] look into using opentelemetry-rust/opentelemetry-proto instead of our own lib

[spencergilbert]

opentelemetry-rust/opentelemetry-proto

Would be nice to track the official crate for our proto needs here, however at the time of writing the crate isn't published (open-telemetry/opentelemetry-rust#860) and we have conflicting requirements for dashmap:

error: failed to select a version for `dashmap`.
    ... required by package `opentelemetry-sdk v0.1.0 (https://github.com/open-telemetry/opentelemetry-rust.git?rev=aec7d0b64336dd0e68227ad8eadcb93faed88b84#aec7d0b6)`
    ... which satisfies git dependency `opentelemetry-sdk` of package `opentelemetry v0.17.0 (https://github.com/open-telemetry/opentelemetry-rust.git?rev=aec7d0b64336dd0e68227ad8eadcb93faed88b84#aec7d0b6)`
    ... which satisfies git dependency `opentelemetry` of package `opentelemetry-proto v0.1.0 (https://github.com/open-telemetry/opentelemetry-rust.git?rev=aec7d0b64336dd0e68227ad8eadcb93faed88b84#aec7d0b6)`
    ... which satisfies git dependency `opentelemetry-proto` of package `vector v0.24.0 (/Users/spencer.gilbert/Code/github.com/vectordotdev/vector)`
versions that meet the requirements `=5.1.0` are: 5.1.0

all possible versions conflict with previously selected packages.

  previously selected package `dashmap v5.2.0`
    ... which satisfies dependency `dashmap = "^5.2"` (locked to 5.2.0) of package `file-source v0.1.0 (/Users/spencer.gilbert/Code/github.com/vectordotdev/vector/lib/file-source)`
    ... which satisfies path dependency `file-source` (locked to 0.1.0) of package `vector v0.24.0 (/Users/spencer.gilbert/Code/github.com/vectordotdev/vector)`

failed to select a version for `dashmap` which could resolve this conflict

[spencergilbert]

This doesn't seem super feasible, without pulling in opentelemetry-rust/opentelemetry-proto into several internal libs (vector-core, value, codecs) as we need to have access to one of the types to implement traits that we need for functionality.

As this would pull in a bunch of build/prost/protoc requirements into a number of our internal libs this seems like a good reason to maintain our internal lib/opentelemetry-proto crate.