Runtime: MemoryPool<T>.Shared.Rent should zero-init returned buffer

[GrabYourPitchforks]

See https://github.com/dotnet/corefx/issues/25843 for earlier discussion on this. In a nutshell, there is some evidence that application developers are beginning to use the Rent APIs as drop-in replacements for new byte[...], but they don't realize that they're getting back a buffer _that might already have previously computed data_. This could lead to applications misbehaving (because they expect zero-init) or information disclosure attacks.

[jkotas]

As I have said in dotnet/runtime#24416, this is a unacceptable behavior/performance change. It is not binary breaking change, but still pretty significant.

[jkotas]

ArrayPool is basically C malloc/free, with all the problems that come with it. Use of uninitialized data is just one of them, and by far not the worst one because of you are likely to find it pretty quickly. For example, I have seen multiple-release or use-after-free bugs introduced by our own skilled developers (e.g. https://github.com/dotnet/coreclr/pull/16512#discussion_r170152494) that are much worse.

I think we should be rather looking at the same (imperfect) solutions that this is addressed by in C: static analysis and diagnostic hooks.

[ViktorHofer]

Levi I agree with what Jan said. Now what's the desired action here? Can we even do anything (analyzers) here till 2.1? Otherwise I would just post-pone it to future.

[joperezr]

I agree with @jkotas comment above so I'm closing this one for now. @GrabYourPitchforks feel free to re-open if you think we should do something different here.