Add spans support to CodedInputStream

[mkosieradzki]

Supersedes #7

[jtattermusch]

Fixed in #9. You can rebase and the diff should disappear from this this PR (btw, I think fixes like this should be in a separate commit - then it's easier to remove then once it has been fixed in the target branch).

[mkosieradzki]

Done

[jtattermusch]

@mkosieradzki I still have this PR on my backlog, but i got busy with fixing some unrelated gRPC C# issues recently. Sorry for delay!
I also spent some time prototyping what should become the new serialization/deserialization API for gRPC C# so that we can make use of the new protobuf API (and thus be able to process gRPC messages without performing any additional copies). The sketch is here:
grpc/grpc#16367 (the new (de)serialization API)
grpc/grpc#16371 (prototype of how accessing reading native segmented buffer can work in C# when receiving message)

[jtattermusch]

as a side note, once concern I still have with this PR (and I have trouble coming up with a better idea) is
the way we are exposing the ref ReadOnlySpan<byte> immediateBuffer in the API publicly - which basically exposes the internals of the implementation and presents a risk of breaking the API in the future.
My thoughts (i'm not leaning one way or another):
One option would be to just expose e.g. public long ReadInt64(ref ParsingContext context) where ParsingContext would be opaque to users, but that would in turn require declaring ParsingContext as a ref struct, which can be a problem for backwards compatibility IMHO.
Also the need for ref argument bothers me a bit, it just makes the API look a bit messy (and at the same time I know there's no easy way around it).

[jtattermusch]

CC @davidfowl in case you have opinions.

[kwaclaw]

Just curious: Is this issue still actively considered?

[davidfowl]

I think the approach here is solid. Do these methods all need to be exposed publicly?

[jskeet]

@davidfowl: Yes, I'd expect that they need to be public as they'll need to be called from generated code. Unfortunately I don't have time to review this carefully right now, due to other commitments.

[jtattermusch]

@davidfowl yes, they need to public which is the reason why I am hesitant with API as is (for internal API the same approach would be perfectly fine).

[prat0088]

This PR looked useful. Is it shelved?

[jtattermusch]

@prat0088 the plan is for fast Span-based parsing to land in one form or another (design discussion are in progress), but there is currently no ETA.

Another take on the Span-based parsing is protocolbuffers#5888 and this PR will probably be superseded by it. Stay tuned.