Remove the unsafe code from Kestrel

[davidfowl]

This is more of an aspirational goal instead of something we would immediately do but we should have enough primitives in the BCL now that this is viable. Of course there might be a tiny performance hit but it might be worth it if we can remove all of the unsafe code.

cc @DamianEdwards @blowdart @halter73 @KrzysztofCwalina @benaadams

[benaadams]

Be nice to do it and not get a performance hit. For example if the Jit could recognise slice advancing and propagate bounds checking; as well as elide slice bounds checking and secondary span creation so that; in the correct pattern, it could be as near cost to a pointer bump

[blowdart]

@benaadams don't take this away from me

[KrzysztofCwalina]

@davidfowl, do you consider the http parser to be "kestrel"? If yes, do you think we can remove unsafe code from the parser?

[davidfowl]

@KrzysztofCwalina yes and yes. I had a branch here in the 2.0 time frame before JIT optimizations on span and the performance hit was too big https://github.com/aspnet/KestrelHttpServer/tree/davidfowl/ideal-parser. I need to go back to it now that those things were addressed.