[http-client-csharp] Do we still need CSharpType? #7162
Description
There once was a discussion around "source of truth" that we would like to decide which class should carry some property of a type, such as Name, Namespace, GenericArguments, etc.
In autorest.csharp, the CSharpType works as if it is a union type of System.Type and our TypeProvider, by calling FrameworkType or Implementation property, we could distinguish which variant this CSharpType comes from.
In our MTG here, CSharpType has been reduced to only carry the information that works as a "shell" of a type, such as name, namespace, generic arguments, declaring type, etc. And TypeProvider carries something more - including the implementations, because majority of the instance of TypeProvider are "emittable", we could write them onto the disk as a cs file, and we should.
But during the developing of our Azure Plugin and Azure Mgmt Plugin, we find that the boundary between them are blurry now.
Wei is working on a feature about SystemObjectType, which represents a System.Type from an existing library. This is useful in mgmt generator because in mgmt, we would like some particular models provided by the core azure libraries to be "replaced" by some classes defined in our mgmt core libraries Azure.ResourceManager to produce a more unified SDK library.
We could notice that this SystemObjectType also holds an instance of System.Type - then what if we use it to represent a string? It should be capable of.
Therefore I would like to propose that we should remove the class CSharpType, and wherever we used to use CSharpType, we could replace it with a specific TypeProvider.
For those previously are a CSharpType associated with a System.Type, we could have a FrameworkTypeProvider which produces you back the System.Type - and the writer should also work fine because the writer only cares the namespace, name, and generic arguments of the type, all these things are suitable for a TypeProvider to have.
Also this would make our "reference map" to be possible. Currently, all the signatures are using CSharpType, we could never know where this type comes from, therefore we could not build a reference map from our client types (root types). But if we use TypeProvider in those signatures, we should be able to build a reference type just using our TypeProviders, and on this part, we do not have to rely on Roslyn any more.
To summarize, my proposal is that we could remove CSharpType and combine its functionality into TypeProvider, or a derived type of TypeProvider (for instance FrameworkTypeProvider).
This could be a big change, but I think this should be good to simplify our code base, and make it more reliable.