Add state to new connection view

[rablador]

Connection details and buttons should change depending on the tunnel state, just like the old connection view.

---

This change is 

[linear]

IOS-960 Add state to connection view

[buggmagnet]

Somehow, when building MockRelease I cannot get multihop PQ to work, and I'm not sure why.

Reviewed 15 of 16 files at r1, all commit messages.
Reviewable status: 15 of 16 files reviewed, 5 unresolved discussions (waiting on @rablador)

---

ios/MullvadVPN/View controllers/Tunnel/TunnelViewController.swift line 14 at r1 (raw file):

import UIKit

class STunnelViewController: UIViewController, RootContainment {

This single letter change broke Release builds 🙈 🫠

---

ios/MullvadVPN/Views/SplitMainButton.swift line 15 at r1 (raw file):

    var image: ImageResource
    var style: MainButtonStyle.Style
    var disabled = false

Same comment about default values, this also guarantees that we cannot have default values sneakingly doing the wrong thing when we don't expect them.

---

ios/MullvadVPN/View controllers/Tunnel/FeatureIndicators/FI_TunnelViewController.swift line 191 at r1 (raw file):

        guard let connectionViewProxy = connectionController.view else {
            fatalError("Invalid view state")

Given that the view property on UIHostingController is declared as UIView! we can do the same here and force unwrap.
The documentation also says that the view will be loaded at runtime if it's nil so we should be safe here too.

The same goes for the mapView above

---

ios/MullvadVPN/View controllers/Tunnel/FeatureIndicators/ConnectionViewViewModel.swift line 137 at r1 (raw file):

}

extension ConnectionViewViewModel {

nit
I wonder if we want to have both the ViewModel and its ViewBuilder in the same file.
I think it'd be nice to separate concerns (data / UI) and have the extension either in ConnectionView because it's used there, or just as a standalone extension.

What do you think ?

---

ios/MullvadVPN/Views/MainButton.swift line 14 at r1 (raw file):

    var text: LocalizedStringKey
    var style: MainButtonStyle.Style
    var disabled = false

Let's remove that default value and specify it in the #Preview macro below instead

[rablador]

Reviewable status: 15 of 16 files reviewed, 5 unresolved discussions (waiting on @buggmagnet and @rablador)

---

ios/MullvadVPN/View controllers/Tunnel/TunnelViewController.swift line 14 at r1 (raw file):

Previously, buggmagnet wrote…

This single letter change broke Release builds 🙈 🫠

Oh man, I did that to test things out at some point, but forgot to change back... 🙈

---

ios/MullvadVPN/View controllers/Tunnel/FeatureIndicators/ConnectionViewViewModel.swift line 137 at r1 (raw file):

Previously, buggmagnet wrote…

nit
I wonder if we want to have both the ViewModel and its ViewBuilder in the same file.
I think it'd be nice to separate concerns (data / UI) and have the extension either in ConnectionView because it's used there, or just as a standalone extension.

What do you think ?

Yeah, I think you're right. I wanted to keep the view itself very clean, but I went a bit too far.

---

ios/MullvadVPN/View controllers/Tunnel/FeatureIndicators/FI_TunnelViewController.swift line 191 at r1 (raw file):

Previously, buggmagnet wrote…

Given that the view property on UIHostingController is declared as UIView! we can do the same here and force unwrap.
The documentation also says that the view will be loaded at runtime if it's nil so we should be safe here too.

The same goes for the mapView above

Done.

---

ios/MullvadVPN/Views/MainButton.swift line 14 at r1 (raw file):

Previously, buggmagnet wrote…

Let's remove that default value and specify it in the #Preview macro below instead

I didn't want to make them mandatory since that's not how buttons tend to work. They're usually enabled by default, letting you disable them if you explicitly want to.

[buggmagnet]

Reviewed 5 of 5 files at r2, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved

[github-actions]

🚨 End to end tests failed. Please check the failed workflow run.