feat: SQL Server database project, with tsqlt tests

Purpose

The purpose of this PR is to enrich the SQL Server support. Here is a video that walks through the changes and does a demo: https://youtu.be/PJV-JueZUmk

Overview

• Created 2 new database projects
  • Eventuous.SqlServer.Database.csproj
  • Eventuous.Tests.SqlServer.Database.csproj

Each of these database projects have 0 impact on code that Eventuous deploys.

Eventuous.SqlServer.Database.csproj

full path: src/SqlServer/src/Eventuous.SqlServer.Database/Eventuous.SqlServer.Database.csproj

• Does not effect how the Eventuous deploys the SQL Server database schema
• Store database definition, matching the migration files defined here: Scripts
• The reason those migration Scripts are not "good enough" is because they do not allow us to harness the power of SQL Server database projects:
  • Static code analysis
  • DACPAC enabling automated testing withing docker
• Within this project are also a few things to enable tSQLt testing
  • Dockerfile.db-from-dacpac deploys the database to a containerized database with the DACPAC using sqlpackage. This allows to initialize a ephemeral SQL Server database for automated testing

Static code analysis

This is a mechanism that allows us to identify code smells and other possible issues with the SQL definitions. Some of those are too opinionated for Eventuous, such as the need for a transaction. Those false positive things can be suppressed in the StaticCodeAnalysis.SuppressMessages.xml file. Right now there are 4 things being suppressed. As a follow-up PR to this one, I'll create Issues to address those.

DACPAC

If you are not familiar, a .dacpac file is a build artifact as a result of building a database project. That .dacpac file can then be used to "Publish" to a database. Pairing this with docker allows to create temporary containerized databases for various purposes, but what I'm adding here is focused on tSQLt testing.

Eventuous.Tests.SqlServer.Database.csproj

full path: ‎src/SqlServer/test/Eventuous.Tests.SqlServer.Database/Eventuous.Tests.SqlServer.Database.csproj

• Contains tSQLt tests. Learn more about the testing framework here
• Dockerfile.eventuous-db-tsqlt-runner‎ creates and runs the database tests on the ephemeral SQL Server database I mentioned above.

How would it interact with the primary project? Those script are included in the database project but remained in the main project?

How would it interact with the primary project? Those script are included in the database project but remained in the main project?

There is no formal interaction between the main project and this new database project. If scripts are changed, we'd need to change them in both places for accuracy.

The main project holds the scripts needed for migrating the database. The new database project is needed for tsqlt testing and static code analysis. Violations of tests or static code analysis can be a build failure to alert us of breaking schema changes.

Maybe use project file links to share the scripts between those two projects?