Add support for partial success in an OTLP export response [2]

[joaopgrassi]

Fixes #2454, Closes #2636

This is a second take on #2636. It's basically the same changes, except it uses rejected_<signal> semantics instead of accepted_<signal> as discussed in the PRs and in the spec meeting on 7/19/2022.

Changes

This PR adds guidance around how servers can signal a partial success to clients. It indicates in which situations servers can respond with a partial success and how the fields introduced in opentelemetry-proto #414 should be populated.

I also refactored the OTLP/gRPC Response section a bit, to make it consistent with the HTTP one. The main inconsistency I found was that the gRPC section did not have clear sections for Success, Failure as the HTTP does. Now both share the same sections and the wording should be consistent between the two.

Related
Proto change: open-telemetry/opentelemetry-proto#414

cc @tigrannajaryan @jmacd @jsuereth @jack-berg @reyang @yurishkuro

[joaopgrassi]

Hi all, just an update on the current state of this PR:

All discussions are solved and I think we should be good to go!

The last thing to be solved (here) was around using the partial success to convey warnings/suggestions to clients when ALL the data was accepted.

This is useful, for example, when the server did some massaging on the data (character normalization) and wants to send a "warning" to clients that this happened. Another usage would be to signal suggestions to clients, e.g. "hey you are sending the data via a less efficient/secure way, you should do xyz" like @reyang suggested here.

Let me know your thoughts.

[jmacd]

@joaopgrassi please rebase (or otherwise resolve "This branch is out-of-date with the base branch")?

[joaopgrassi]

@jmacd rebased and also allowed edits from maintainers on the branch, in case it needs again and I'm away.