Add DAITA into TunnelSettings

[mojganii]

This PR integrates DAITA settings into the tunnel settings, enhancing configuration flexibility and ensuring seamless DAITA support within the tunnel environment.

---

This change is 

[linear]

IOS-791 Add `DAITA` settings into tunnel

[rablador]

Reviewed 23 of 32 files at r1, 10 of 10 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @mojganii)

---

ios/MullvadREST/Transport/Shadowsocks/ShadowsocksLoader.swift line 47 at r2 (raw file):

                didUpdateSettings: { [weak self] _, latestTunnelSettings in
                    guard let self else { return }
                    if settingsStrategy.shouldReconnectToNewRelay(

Isn't this used more as a general check for changes in constraints? At least this seems to be the only application at this point. Perhaps shouldReconnectToNewRelay should be renamed to constraintsHaveChangedor something similar?

---

ios/MullvadSettings/TunnelSettingsV6.swift line 28 at r2 (raw file):

    public var tunnelMultihopState: MultihopState

    /// Whether Multi-hop is enabled.

"DAITA" instead of multihop

[buggmagnet]

Reviewed 21 of 32 files at r1, 10 of 10 files at r2, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @mojganii)

---

ios/MullvadSettings/DAITASettings.swift line 16 at r2 (raw file):

    case off

    public var isEnabled: Bool {

Do we really need this for an enum that is a bool value ?

---

ios/MullvadSettings/TunnelSettingsPropagator.swift line 21 at r2 (raw file):

public class SettingsObserverBlock: SettingsObserver {
    public typealias DidUpdateSettingsHandler = (SettingsPropagation, LatestTunnelSettings) -> Void

This looks like a delegate pattern except it's called observer instead.
Why do we pass a settings handler which you can also subscribe to, when the object (SettingsObserverBlock) we are listening to, already gives us an update on the settings ?

From the use I can see, we don't use that argument anywhere, we should remove this.

[rablador]

Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @buggmagnet and @mojganii)

---

ios/MullvadSettings/DAITASettings.swift line 16 at r2 (raw file):

Previously, buggmagnet wrote…

Do we really need this for an enum that is a bool value ?

Could be that we'll have .auto or something in the future as well. Also, it's consistent with multihopState.

[mojganii]

Reviewable status: 25 of 33 files reviewed, 4 unresolved discussions (waiting on @buggmagnet and @rablador)

---

ios/MullvadREST/Transport/Shadowsocks/ShadowsocksLoader.swift line 47 at r2 (raw file):

Previously, rablador (Jon Petersson) wrote…

Isn't this used more as a general check for changes in constraints? At least this seems to be the only application at this point. Perhaps shouldReconnectToNewRelay should be renamed to constraintsHaveChangedor something similar?

it's not about the constraints, it's all about whether reconnecting to the new relays should be done by some part changing in settings or not. the major responsibility for this part is that forces relaySelector to pick new relay if needed, regardless if it's ShadowSocks or Direct.

---

ios/MullvadSettings/DAITASettings.swift line 16 at r2 (raw file):

Previously, rablador (Jon Petersson) wrote…

Could be that we'll have .auto or something in the future as well. Also, it's consistent with multihopState.

yes, it's for consistency.

---

ios/MullvadSettings/TunnelSettingsPropagator.swift line 21 at r2 (raw file):

Previously, buggmagnet wrote…

This looks like a delegate pattern except it's called observer instead.
Why do we pass a settings handler which you can also subscribe to, when the object (SettingsObserverBlock) we are listening to, already gives us an update on the settings ?

From the use I can see, we don't use that argument anywhere, we should remove this.

Done.

---

ios/MullvadSettings/TunnelSettingsV6.swift line 28 at r2 (raw file):

Previously, rablador (Jon Petersson) wrote…

"DAITA" instead of multihop

Good catch!

[rablador]

Reviewed 8 of 8 files at r3, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @buggmagnet)

[buggmagnet]

Reviewed 2 of 32 files at r1, 8 of 8 files at r3, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @mojganii and @rablador)

---

ios/MullvadSettings/DAITASettings.swift line 16 at r2 (raw file):
But that doesn't mean it's a good idea 😭

Could be that we'll have .auto or something in the future as well.
YAGNI

Anyhow, it's not a big deal.

[github-actions]

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