Change Linux fetch timeout behavior for chain building

[vcsjones]

This gets the ball rolling on what I guess is going to require some discussion to unify UrlRetreivalTimeout on Windows / Linux.

Change the UrlRetrievalTimeout behavior on Linux to match Windows' existing behavior of using a per-operation timeout rather than cumulative.

Add some tests for operations that time out.

Contributes to #38875
Closes #40578

[ghost]

Tagging subscribers to this area: @bartonjs, @vcsjones, @krwq
See info in area-owners.md if you want to be subscribed.

[bartonjs]

Suggested change

	public TimeSpan RespondDelay { get; set; }
	public TimeSpan ResponseDelay { get; set; }

Reads a bit better to me, particularly in the formatted strings.

[bartonjs]

NIt: too many blank lines

[bartonjs]

@vcsjones This portion of the change seems reasonable to me... are you expecting anything else to come in to it soon, or should we just check outerloop and merge this, with followups done in a different PR? (Just getting sensitive about timing)

[vcsjones]

@bartonjs I think outerloop is going to fail; I'm looking at fixing a Windows test today. Should be in by COB.

[vcsjones]

@bartonjs this is ready for review and and outerloop run, assuming there is nothing else that needs to be addressed immediately.

[vcsjones]

Random thought: we could do it both ways if we wanted to. Windows lets you have a cumulative timeout with CERT_CHAIN_REVOCATION_ACCUMULATIVE_TIMEOUT. Would there be interest in an API that lets folks get the old behavior back on Linux, and use this in Windows? (Post 5, of course)

[bartonjs]

Would there be interest in an API that lets folks get the old behavior back on Linux, and use this in Windows?

I'm open to the idea, especially if it seems like anyone actually wants it. Clearly it's how I thought the Windows one worked, but early in .NET Core we didn't have the capability of writing the tests reliably (Since it wasn't until after CertificateRequest/AsnReader/AsnWriter/CustomRootTrust that we could do it in a reasonable/self-contained way).

• https://apisof.net/catalog/System.Security.Cryptography.X509Certificates.X509Chain.Build(X509Certificate2) has 4.8% usage
• https://apisof.net/catalog/System.Security.Cryptography.X509Certificates.X509Chain.ChainPolicy has 3.8% (79% of X509Chain usage)
• https://apisof.net/catalog/System.Security.Cryptography.X509Certificates.X509ChainPolicy.UrlRetrievalTimeout has 0.6% (12.5% of X509Chain, 15.8% of ChainPolicy usage).

So it's unclear how relevant such an option would be to anyone, but I'm happy to entertain things if we feel it's relevant. (Maybe all 0.6%/12.5%/15.8% want the feature, maybe it's none.)

[vcsjones]

especially if it seems like anyone actually wants it

I have no idea. I'm easily excited by things 7 people on the planet want.

Innerloop failure seems unrelated, I can address any additional feedback Thursday AM.

[bartonjs]

/azp run runtime-libraries outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vcsjones]

Hmm. Looking at failure.

[bartonjs]

In case you hadn't had these observations already:

• The test only failed on Win8.1, it passed on Win10
• It failed by succeeding the chain, after 1 minute, 30 seconds.

Conclusion: Win8.1 had a bigger max value than Win10.

Solution1: Figure out the Win8.1 limit, and if it's acceptable, change the test to use that on Win8.1.
Solution2: Make the test just exit immediately if running on Windows8.1 or lower.

[vcsjones]

I went with solution 2 in the interest of time, and I at risk of losing power / internet due to weather, so wanted to get something in.

[bartonjs]

/azp run runtime-libraries outerloop

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[vcsjones]

None of the failures appear related to this PR.