CSHARP-4969: Fix failing CSFLE mocked kms tls tests

[adelinowona]

No description provided.

[JamesKovacs]

Technique seems reasonable, but we still have some variability to account for in the returned exception messages.

[JamesKovacs]

This approach seems reasonable and passes on Linux for netstandard2.0, but is failing on netstandard2.1 due to differing error messages. The failing test is:

MongoDB.Driver.Tests.Specifications.client_side_encryption.prose_tests.ClientEncryptionProseTests.MongoDB.Driver.Tests.Specifications.client_side_encryption.prose_tests.ClientEncryptionProseTests.KmsTlsOptionsTest_kmsProvider___azure___certificateType__TlsWithoutClientCert__async__True_

The error on netstandard2.1 (Linux) is:

[2024/02/15 10:03:09.316] FAILURE: Expected string "The decryption operation failed, see inner exception." to contain "Unable to read data from the transport connection: Connection reset by peer.". (failure)
[2024/02/15 10:03:09.316] Expected string "The decryption operation failed, see inner exception." to contain "Unable to read data from the transport connection: Connection reset by peer.".

This is the failing variant:
https://spruce.mongodb.com/task/dot_net_driver_csfle_with_mocked_kms_tests_linux_2004__version~7.0_os~ubuntu_2004_topology~replicaset_ssl~nossl_test_csfle_with_mocked_kms_tls_netstandard21_patch_fdd2ba5270a3547fcd2ab8ad5a558d5f7e4f26fd_65ce3e9061837d1f8ca0a44d_24_02_15_16_40_50?execution=0&sortBy=STATUS&sortDir=ASC

[adelinowona]

I ran the test again a couple more times to see if the differing error here was just a legit error I missed but from my testing, I haven't been able to reproduce that error again. So it seems it have just been a random case. I researched the error a bit and it seems that the inner exception would have most likely been "Unable to read data from the transport connection: Connection reset by peer." and it just got wrapped inside the The decryption operation failed exception in this particular run of the test.

As of now my take is that this was just a random failure, and we can just go ahead with just the two error messages I am currently capturing and if that other error keeps popping enough then we can investigate further and add it to the expected exception messages.

[JamesKovacs]

Thanks for investigating. I restarted the failed variants on the patch build. Let's see if they go green this time. (It'll be an exercise for our future selves to make these tests less flaky.)

[JamesKovacs]

LGTM