Work towards merging TdsParser

[MichelZ]

This is for tracking purposes connected to #1261
I would like to merge TdsParser to a single code base netfx/netcore

The approach I'd like to take is this:

• Do small PR's first which only change code style to align netfx/netcore codebases
• Do small PR's that target specific things (e.g. change from Types to type aliases e.g. Int32 to int)
• Do more PR's that align code but do need code changes

This way (I hope?) changes are small-ish and/or low-riskish, so that they can be reviewed fairly fast (much easier than "big bang" PR's IMHO)

Hope that makes sense, if not just tell me please :)

• Align Newlines: Align newlines between netfx and netcore #2954
• Align whole comments: Align whole comments between netfx and netcore #2955
• Align type aliases Align Type aliases between netfx and netcore #2957
• Align keywords Align keyword ordering and operation ordering netfx/netcore #2958
• Align var vs Type This one aligns var vs Type between netfx and netcore #2959
• Align redundant namespaces Remove redundant Namespace to align netfx/netcore #2960
• ADP.IsEmpty -> string.IsNullOrEmpty Align ADP.IsEmpty -> string.IsNullOrEmpty #2961
• Align BitConverer -> BinaryPrimitives Align BitConverter/BinaryPrimitives usage netfx/netcore #2963
• Align Task usage / ArrayPool / IsColumnEncryptionSupported netcore/netfx #2982
• Move ReliabilitySection / BestEffortCleanup to framework specific files #2984

#2839 also has an impact on this, because removal of SQL 7.0/2000 code means a lot less #IF NETFRAMEWORK constructs, so holding off with aliging SQL7.0/2000 specific code until we know if it needs to stay or can be removed

[edwardneal]

Thanks for this @MichelZ - these bundles of changes look good to me.

Another pattern of changes will also need to be made at some point, across TdsParser and other core parts of SqlClient: Constrained Execution Region support exists in netfx, but was removed in netcore. This is (roughly) a no-op, but each instance adds ~45 lines to the diff and it's usually inside methods which are otherwise identical. It's probably not necessary as part of this cleanup, but it'd be a good idea to port the CER support to netcore before starting to merge identical methods.

On a wider point: I think it makes sense to use the TdsParser approach as a template for the core parts of SqlClient.

[MichelZ]

I think that's it for now with the more trivial stuff. Once these are merged I'll continue with some more "meaty" one's :)
I do hope these are mostly straight forward to review and don't take up too much of anyone's time.

[benrr101]

Thanks for taking a stab at merging this behemoth of a class 👍 I'll do my best to look at these PRs in a timely manner, but keep in mind we need two signoffs on them to get them merged. I'll also do my best to encourage my teammates to look at your PRs as well 😅

That being said, I think for the smaller changes, it might be more beneficial to combine a couple together - eg, comments and comment typos could be rolled into a single comment PR. I've been trying to structure my PRs such that each commit is a complete item. So, eg, if you had a PR for comments, one commit could be getting the blocks aligned, the second could be to fix the typos. You don't need to go back recall the PRs that are currently out, but it might be beneficial going forward. It's a delicate balance between too much overhead per PR and too much to review in a single PR.

My strategy for merging classes has been to create a "merge file" in the commit history of the PR. Basically indicate what blocks of code are from only one side of the merge. Then, merge work through each chunk of conflicts to either resolve as one or the other (eg, Int32 vs int) or leave with an #if NETFRAMEWORK sort of thing.