[wasm] Implement NetworkInterface.GetIsNetworkAvailable and NetworkChange.NetworkAvailabilityChanged

[MaximLipnin]

Since we don't have access to the network cards on browser/WASM, the entire System.Net.NetworkInformation assembly is going to be PNSE excepting tho methods:

• NetworkInterface.GetIsNetworkAvailable
• NetworkChange.NetworkAvailabilityChanged

These two methods could probably be implemented on top of https://developer.mozilla.org/en-US/docs/Web/API/NavigatorOnLine/onLine

[ghost]

Tagging subscribers to this area: @dotnet/ncl
Notify danmosemsft if you want to be subscribed.

[lewing]

https://developer.mozilla.org/en-US/docs/Web/API/Network_Information_API

[maraf]

How should the .NET API behave when the browser API is not available?

We have several situations that can happen

• The browser API is not available for NodeJS/V8.
• This browser API is well supported on all new browsers, but if we speak in general, it could happen, that the API we are relying on is missing/disabled/monkey patched etc.

We could deal with it in these ways

• Silently do nothing (not ideal, but for things like this, it won't fail the application)
  • Pros: app always "works"
  • Cons: developer doesn't know if it works or not
• Let it fail in javascript (like Cannot read properties of undefined (reading 'onLine') when navigator is not there)
  • Pros: no hardcoded condition in runtime
  • Cons: hard to understand error message for .NET developer
• On runtime (when running the code) check for the API and when it's missing, throw in .NET (probably NotSupportedException)
  • Pros: works when the API is there on any platform
  • Cons: we don't have a way to tell the developer that is could throw this way
• Hardcoded condition where we support it and where we don't
  • Cons: the API could still be missing on user's browser; we aren't able show this to the developer (via analyzer)
• Anything from above + provide a way for the developer to implement a polyfill.

cc @lewing @pavelsavara @kg

[kg]

For NetworkInterface.GetIsNetworkAvailable:

• In any case where we cannot return a valid yes/no answer, we should throw. The developer and user may develop false expectations otherwise. This will be cases where the host doesn't have the API or the API has been disabled/monkeypatched. We should not produce speculative values like "well, this is a blazor app, so they're probably connected to the network, unless it's on 127.x.x.x"
• It seems like there is no explicit spec for how navigator.onLine works, so we're just hoping that it's close enough to what we want. The MDN pages at least suggest it is, so that's good. But we should be wary of making existing good code do strange things by redefining the meaning of this information.

For the NetworkChange.NetworkAvailabilityChanged event I think as long as it is theoretically possible for the event to ever fire, it should be fine to subscribe to it, but we should throw NSE or PNSE if it's never going to work. We would want to use the online/offline events for this.

Keep in mind that both of these are probably at risk of getting killed by browser anti-fingerprinting measures or something like that.