Deprecate syntax serialization logic.

[CyrusNajmabadi]

Background and Motivation

The roslyn API contains a mechanism to serialize a syntax node to a stream, and then read it back again.

The methods are:

public class SyntaxNode
{
    public virtual void SerializeTo(Stream stream, CancellationToken cancellationToken = default)
}

public class CSharpSyntaxNode
{
   public static SyntaxNode DeserializeFrom(Stream stream, CancellationToken cancellationToken = default)
}

// And the VB equivalent.

These APIs were created for the IDE back in the 32bit days so that teh IDE could dump trees to memory-mapped files and read them in on demand when needed. This was terrible for performance, but it allowed us to still run in 32bits.

The IDE has not used this in many years (since VS moved to 64bit). Looking online (github search), i can't find any usages of this api either.

Note: this API cannot be used to persist data to a stream that is then read in in a later session. Nor can it be used for cross process communication. This is because the 'object reading/writing' system keeps references to in memory data in the bytes it writes out. Specifically, it keeps arrays of "registered System.Types" in memory, and then writes out indices into that array. That array isn't deterministically created. It will change from VS session to session, and will be not be the same in VS and in our OOP process.

As such, this API exists solely for a host to write things to memory mapped files, and only read it back within the same session. In other words, it only exists for that exact use case we had in roslyn when we were 32 bit.

Given that we're not 32bit, are not using this anymore, and there are no usages of this in the wild, i recommend deprecating this API. Currently, we have to have complexity in a lot of places to support it, and it accounts for ~20k lines of code we ship: #70277

Removing this will be a nice savings in metadata and IL, and it will allow us to simplify a bunch of our serialization system. Specifically, our serializtion system will not have to have an object registration system anymore. It can just be about types writing out their contents in an explicit fashion (which needs no type registration).

[333fred]

API Review

• We're ok with this deprecation
• We'll try to get an Obsolete(warning: true) and a NFW on usage into 17.8 so we can be more sure on whether this is in use or not.

Conclusion: Approved

[CyrusNajmabadi]

Deprecation has gone in: #70365
A later PR can remove the functionality entirely. That PR is currently in draft here: #70277