Fix 5 broken tests in SignatureTrustAndValidityVerificationProviderTests, add Linux workaround for adding cert to store

[heng-liu]

Fix 5 broken tests in SignatureTrustAndValidityVerificationProviderTests
Add Linux workaround for adding cert to store

Bug

Fixes: NuGet/Home#8934
Regression: No

• Last working version:
• How are we preventing it in future:

Fix

Details:
1.Fix following 5 tests by using different messages for different platforms

GetTrustResultAsync_RepositoryCountersignatureWithUntrustedRoot_InAllowedUntrustedRootList_AllowUntrustedFalse_SucceedsAsync
GetTrustResultAsync_WithUnavailableRevocationInformationInVerify_WarnsAsync
GetTrustResultAsync_WithUnavailableRevocationInformationAndAllowIllegal_WarnsAsync
GetTrustResultAsync_WithUnavailableRevocationInformationAndAllowUnknownRevocation_WithOfflineRevocationMode_WarnsAsync
GetTrustResultAsync_WithTrustedButExpiredPrimaryAndTimestampCertificates_WithUnavailableRevocationInformationAndAllowUnknownRevocation_WarnsAsync

2. Use workaround for Linux as X509Store.Add() has a delay problem on Linux.
   X509Store.Add() on Linux is racing with X509Chain.Build dotnet/runtime#32608

3.Reformat the assertion for different APIs.

Testing/Validation

Tests Added: No
Reason for not adding tests:
Validation:

[dtivel]

First, the comment ("once a second") does not match the implementation (500 milliseconds). If .NET Core's internal poll is 1 second, our window should be 2 seconds, minimum.

Second, in general I'd prefer polling over a hard-coded sleep; however, some consideration should be paid as to the impact of chain building results possibly being cached before a test actually runs. (This whole discussion is limited to Linux, and I don't know what level of caching if any exists on Linux.)

Third, why are we not subject to the longer 30-second interval Jeremy mentions? We load and modify the store within 1 second. Here's Jeremy's relevant comment:

The 1 second interval is how often it'll check for a new last modified time on the store. LMT values are only to the second, so if you end up causing the chain processor view of the store to load and modify the store again during the same second, you'll have to wait for the longer interval (30 seconds) before you actually see the benefit (that's the "just in case LMT is disabled for this filesystem, or we had a level-of-refinement problem, or clock adjustments" failsafe).

[heng-liu]

Thanks! Changed to use polling and set more than 30 seconds for the upper limitation.

[zkat]

Can you put a Thread.Sleep(1500) or 2000 right before this loop? We know for sure that we at least need to wait a second, so we should lead with that. Otherwise there's a pointless chain build that we already know will fail.

[heng-liu]

Thanks for review! The problem is the test time on Linux has extended from about 45mins to 90mins.Is that acceptable? Or shall I log the time to see if the time of packaging tests doubled?

[heng-liu]

I truned the "verbosity -detailed" on and found a test runs 10-40 mins
ExecuteCommandAsync_WithAmbiguousMatch_ThrowsAsync

Raised an issue NuGet/Home#9315 and I will investigate it.