Don't access CookieContainer unless needed

[BrennanConroy]

While experimenting with blazor-webassembly and the SignalR C# Client I found that this is the only blocking (not-user fixable) issue for consuming the client with the LongPolling transport.

We set the _httpConnectionOptions.Cookies property to a new object in the HttpConnectionOptions constructor, so by default it isn't null and will access the httpClientHandler.CookieContainer property which will throw in mono wasm.

We want this for 3.1 because blazor-wasm is scheduled for May 2020 and we would like the SignalR Client to work at that time.

No tests because this isn't unit-testable without making a full end-to-end blazor-wasm + signalr test suite.

@Pilchie for 3.1 approval

[Pilchie]

Approved for 3.1.0-preview3, pending CI build and code review approvals

[analogrelay]

I'm glad it was a pretty straightforward set of changes needed!

@BrennanConroy can you add a Blazor WASM sample to the repo? That way we have at least some idea of the changes a user has to make currently in order to get it to work.

[BrennanConroy]

@BrennanConroy can you add a Blazor WASM sample to the repo?

I'm going to vote for no right now. There is a lot of churn with the HttpClientHandler right now see: #16631 so this would break as soon as I made it

[halter73]

How afraid are we of temporarily broken samples are we really? If you already have a working sample, I say check it in. Then when the API stabilizes, we can fix the sample instead of creating a new one from scratch.

[BrennanConroy]

I tried to add the sample, but it appears to be non-trivial and I wont have any more time to try until after preview3.

Please approve (assuming the change is good :D)

[BrennanConroy]

@aspnet-hello triage https://dev.azure.com/dnceng/public/_build/results?buildId=410635&view=logs

[aspnet-hello]

This comment was made automatically. If there is a problem contact [email protected].

I've triaged the above build. I've created/commented on the following issue(s)
https://github.com/aspnet/AspNetCore-Internal/issues/3261
https://github.com/aspnet/AspNetCore-Internal/issues/3241