chore: Add linux support and containerize the project

[clouths]

Context

Setting up development environment for OpenPerpetuum requires Windows, clone of 3 repositories (OPResource, OPDB, PerpetuumServer2), Steam with the official PerpetuumServer installed to get access to database seed + some data files (customDictionnary, map layers, plantrules). Developing on linux is not possible without modifications. We also need to setup the database with migration script, setup the OPResource as a file server, then you can start the PerpetuumServer2 to connect a game client.

The goal of this PR is to reduce that friction to get started more quickly and support multiple development platform by using containers to be compatible on windows, mac, linux. Note: for windows, using linux containers would be a requirement to keep the initial implementation simple.

When porting the application to linux, one issue came up with the database DistributedTransactions. It turns out the .NET on linux does not support it. For now, it has been disabled but I'll try to find a solution or an alternative.

Description

• Add git submodules for OPResource (as asset) and OPDB (as db)
• Add .env.local where you can configure db password, container ports, asset url, various paths, connection string, type of .net build
• Add template for perpetuum.ini to get dynamic content based on the config
• Add dockerfile for the asset using nodejs to host the file server
• Add dockerfile for the migration that act as the OPDB/apply_all.bat but for linux + also handle updating the PerpetuumData content
• Add multi-stage dockerfile for the server
• Add Makefile to help run commands using docker-compose or equivalent
• Refactor System.Drawing into SkiaSharp

How to setup

Read the README.md file.

Some technical information

• The database uses a local directory as the persistent storage in mssql-data
• The perpetuum-data folder is used during migration but the one used by the server is in a docker volume openperpetuum-data
• DistributedTransactions is not compatible with linux but is enabled by default in the server if you don't pass it to the server environment so the windows build is unchanged.

Improvements

• Ability to detect database migration and run if some change is detected by adding a database schema version to compare with
• Move the template/restore_DB_to_original_state.sql somewhere else
• Able to run DistributedTransactions enabled for linux or find an alternative
• readme to explain how to set up and document how it works
• move database files into a docker volume instead of mounted one

[aqpanaciy]

Regarding using DistributedTransactions, we use a single database and the connection string doesn't change. Therefore, using DistributedTransactions is not necessary. I'm not very knowledgeable about the intricacies of database operation, but after reading the documentation, I found out that:

1. After closing the connection to the database, it is not closed immediately, but is returned to the pool, and when reopened, it is taken from there.
2. For each request inside a TransactionScope, you can open and close your own connection; this is a well-known technique.

Therefore, you can remove: TransactionManager.ImplicitDistributedTransactions = true; in PerpetuumBootstrapper.cs
AND
Rremove: dbConnection.EnlistTransaction(Transaction.Current); in DbQuery.cs (This line of code is responsible for forcing the use of distributed transactions for the current transaction)

With these changes, I was able to launch the server on Linux. And there are no errors when working with the database. I hope this information will at least be useful.

[clouths]

Regarding using DistributedTransactions, we use a single database and the connection string doesn't change. Therefore, using DistributedTransactions is not necessary. I'm not very knowledgeable about the intricacies of database operation, but after reading the documentation, I found out that:

1. After closing the connection to the database, it is not closed immediately, but is returned to the pool, and when reopened, it is taken from there.

2. For each request inside a TransactionScope, you can open and close your own connection; this is a well-known technique.

Therefore, you can remove: TransactionManager.ImplicitDistributedTransactions = true; in PerpetuumBootstrapper.cs AND Rremove: dbConnection.EnlistTransaction(Transaction.Current); in DbQuery.cs (This line of code is responsible for forcing the use of distributed transactions for the current transaction)

With these changes, I was able to launch the server on Linux. And there are no errors when working with the database. I hope this information will at least be useful.

This PR disables it but I have left a default value (true) to keep the same behavior to keep compatibility for the Windows build. If removing the EnlistTransaction do the trick, we might be able to disable it if the live server using the Windows build don't have any issue.

[clouths]

At this point, the PR is almost ready for review.

The client is able to connect and perform all actions tested (chat, enter/leave chat, buy from market, unpack item, activate bot, undock/dock, move, assignments, looting, combat, tutorial, rift)

What is left todo?

• Add readme how how to setup development environment (server, assets, gamma layers) (can be done in a follow-up PR)

[clouths]

At this point, the documentation has been added and the DistributedTransactions config is now correctly applied in the codebase.