Optimistic default connectivity, respect useOfflineMode if set

[ZachNagengast]

There are a few PR's relating to this issue already #281 #260, but this PR simply reverts the change that ignores explicitly setting useOfflineMode in constrained or expensive network conditions to its previous logic (noted here #280 (comment)). Now if useOfflineMode is set it will always be respected, and only if nil will check the monitor for the proper fallback behavior.

In addition to that, it relaxes the default connectivity to assume true until updated by the monitor. This will match the other defaults that were optimistic already:

/// Assume best case connection until updated by the monitor
public var isConnected: Bool = true <- updated from false
public var isExpensive: Bool = false
public var isConstrained: Bool = false

There is still the case where we need a faster initial update, which I believe #259 covers well.

Regarding isExpensive and isConstrained, I think they are less relevant to this library and would be better off left to the developer since both cases would still be able to download a model, only isConnected will require a different code path to potentially succeed - developers can make the decision with their own monitor and UI that would warn the user, e.g. give them the option to continue if they're ok with either case. Future work here could be surfacing that to developers without throwing when there technically is connectivity.

[pcuenca]

Yes, I think you and @DePasqualeOrg in #281 are correct here!

[pcuenca]

I don't have a strong opinion here, I see how it would be the responsibility of the user app whether to allow to proceed. But they can also force behaviour with useOfflineMode, can't they?

[ZachNagengast]

Yes, this is just a bit more lenient default, like @DePasqualeOrg mentioned the default when on a cell connection with expensive bandwidth is to throw, which would definitely be one way to surface the issue to the user - but I'm hoping this is a bit less opinionated / more lenient to reduce any surprises without solid documentation on when and where "non-fatal" network based throws will occur, i.e. the download is only technically impossible when there is no network connection at all.