Tests | Introduce RAII SQL object primitives

[edwardneal]

Description

This change is designed to make sure that the manual tests clean up after themselves and to introduce some consistency.

Many of the manual tests need to create objects - usually tables, stored procedures and UDTs. There are a handful of ways to do this. Some of the AlwaysEncrypted tests have a set of objects describing tables, column encryption keys, etc. The DataTestUtility class has CreateSP, DropSP and similar methods. Some tests have their own helper methods and others manually construct DDL statements. These are also used in various combinations, and most of the time the logic to delete these temporary objects is located in a finally block.

Separately, the objects are created in different scopes - sometimes they're passed as fixtures to the test class, sometimes they're created by the constructor of a test class which implements IDisposable but most of the time they're created by each test.

Lastly, the naming of these is sometimes odd. Sometimes the tests request a random object name, other times they'll use existing helper methods in DataTestUtility, and other times still they'll attempt to use their own logic to generate a unique name.

I'd like to simplify this with a consistent set of RAII-style types which represent database objects, returning its name post-hoc.

This PR starts the process by introducing types for a table, a UDT or an SP. It then applies these to a handful of tests (ApiShould, JsonStreamTest, JsonTest, SqlGraphTable, ParametersTest) to prove that they handle the edge cases. In a few cases (the two changed JsonStream tests) we eliminate test bugs which would always leave a JSON-based table behind, or which would leave files behind on the filesystem if an exception was thrown at the wrong time.

I expect it to take a while to migrate to the RAII types, but it should cut down on resource leaks in the Azure databases.

Issues

None.

Testing

Automated tests should continue to pass.

[ErikEJ]

What does RAII mean exactly?

[edwardneal]

Resource Acquisition Is Initialization - so we create SQL objects when a Table / StoredProcedure / UserDefinedType class is instantiated, and drop the SQL object when the instance is disposed of.