Port BatchParserWrapper from DacFx into the tools service to fix batch execution reliability issues

[kevcunnane]

Why is this needed? Reliability: We're running into issues where the intellisense-parser that's currently used for identifying batches fails in some situations due to edge cases and bugs in syntax for the latest versions of SQL. Batch parsing should be one of the most reliable scenarios as it's vital for query execution, so we need to move away from Intellisense parser which is inherently unreliable against latest in-development SQL versions

Perf: intellisense parsing is slow, and the batch parser implementations are much faster since they just need to identify GO statements, batch them up and (optionally) execute the batches.

Implementation details DacFx contains a copy of the BatchParser code found in Microsoft.Data.Tools.Sql.BatchParser.dll, presumably a fork from a long time ago. It then leverages this in the Product/Source/SchemaSql/Common/ExecutionEngine code, notably the following classes:

• BatchParserWrapper.cs, which implements a simple GetBatches method and is exactly what we need. Using this it's easy to replace the intellisense parser usage. This file can be found at Product/Source/SchemaSql/Schema/BatchParserWrapper.cs
• ExecutionEngine.cs, which is used by the BatchParserWrapper
• Batch.cs which defines a batch.

We should be able to copy this folder over in its entirety - it includes useful settings for executing with ShowPlan and other code, with minimal external dependencies.

Unit Tests Tests are located in Product/Test/DacFx/UnitTests/UTData/TSQLExecutionEngine and again should be ported in their entirety. These are really integration tests as they have to hit a live DB in order to verify correct execution.

Additional notes / future considerations

• Support for SQLCMD execution is built into the batch parser. We should track support of SQLCMD and other features (show plan, show statistics) in issues and leverage this code to do this
• Consideration should be made as to whether this should be put in its own DLL. This would enhance reusability, and in the long run may be beneficial

[abist]

Hey @kevcunnane, which DacFx enlistment are we supposed to use? I don't see BatchParserWrapper.cs file in the enlistments.