chore: add S3EC .NET v2 and v3 test server

[rishav-karanjit]

Issue #, if available:

Description of changes:
Adds dotnet test sever implementation.

Call out
.NET also does not have a way to send EC on encrypt/decrypt path but the tests are configured to send it only on encrypt/decrypt path. So, following tests are skipped:

• crossLanguageTestKmsWithSubsetEncCtxFails on both encrypt and decrypt path of .NET:

  • On encrypt path because EC is not send on each encrypt request
  • On decrypt path because .NET fetches EC from stored meta data. So, these failure is not expected in .NET.

• crossLanguageTestKmsWithEncCtx on encrypt path of .NET:

  • .NET does not send EC on encrypt.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[texastony]

Going to try and call @rishav-karanjit today, I have a few questions.

[texastony]

Requested Change: Make ClientRequest.cs appear exactly like the Smithy Model for the test service.
This should be a very small change.

[texastony]

Issue #, if available:

Description of changes:
Adds dotnet test sever implementation.

Revising the call out

.NET also does not have a way to send EC on encrypt/decrypt path but the tests are configured > to send it only on encrypt/decrypt path. So, following tests are skipped:

• crossLanguageTestKmsWithSubsetEncCtxFails on both encrypt and decrypt path of .NET:
  • On encrypt path because EC is not send on each encrypt request
  • On decrypt path because .NET fetches EC from stored meta data. So, these failure is not expected in .NET.

• On encrypt path because EC is not send on each encrypt request

The above is NOT true; S3EC .NET v2 & v3 to send EC on encrypt, but they send the client's EC.
However, S3EC .NET v2 & v3 only considers the "messages" EC on Decrypt; there is no means to specify the EC from the Decrypt request/outside the context of the message.

• crossLanguageTestKmsWithEncCtx on encrypt path of .NET:
  • .NET does not send EC on encrypt.

This is completely false.
When the customer configures the S3EC .NET, they can specify an EC, and that EC will be used on all Gets.

Testing EC

This PR does not test EC in the S3EC for .NET v2 & v3 at all.
The current conclusion is that we can add this testing later.
This means this is an incomplete base line with respect to EC and the S3EC .NET.
However, it is a complete base line with respect to Key Commitment and the S3EC in .NET.

[texastony]

Suggested change

var encryptionContext = request.Config.EncryptionContext;

[texastony]

Suggested change

public Dictionary<string, string> EncryptionContext { get; set; } = new();