Remove duct from talpid-tunnel

[MarkusPettersson98]

This PR removes duct from the talpid-tunnel crate. While doing so, I refactored some code that is responsible for configuring tun devices to use tun 0.7, up from the previous dependency on tun 0.5. This allowed me to remove spawning an ip subprocess on Linux and instead use syscalls (under the hood).

---

This change is 

[dlon]

Reviewed 3 of 4 files at r1, all commit messages.
Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @MarkusPettersson98)

---

talpid-tunnel/Cargo.toml line 30 at r1 (raw file):

[target.'cfg(any(target_os = "linux", target_os = "macos"))'.dependencies]
tun = "0.7"

Should nix be moved here too?

---

Cargo.lock line 4779 at r1 (raw file):

[[package]]
name = "thiserror"

Would it break anything to bump thiserror elsewhere?

---

talpid-tunnel/src/tun_provider/unix.rs line 94 at r1 (raw file):

impl UnixTun {
    /// Retrieve the tunnel interface name.
    pub fn interface_name(&self) -> Result<String, Error> {

mod.rs implies that Android and Linux/macOS implement a shared interface for Tun.

// macos and linux
type Tun = imp::UnixTun;
type TunProvider = imp::UnixTunProvider;

// android
type Tun = imp::VpnServiceTun;
type TunProvider = imp::AndroidTunProvider;

But there's nothing that enforces this. 😅

Do you think we could improve this?

[MarkusPettersson98]

Reviewable status: 3 of 4 files reviewed, 3 unresolved discussions (waiting on @dlon)

---

Cargo.lock line 4779 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

Would it break anything to bump thiserror elsewhere?

Do you mean in a separate PR? We should probably look at moving to thiserror 2 ourselves, but we will inevitably have both version 1 & 2 in our tree for the foreseeable future:/

---

talpid-tunnel/Cargo.toml line 30 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

Should nix be moved here too?

Sure! I kind of didn't want to do it in this PR since it could easily be removed anyway: https://github.com/mullvad/mullvadvpn-app/pull/7411/files, but now I did it anyway:)

---

talpid-tunnel/src/tun_provider/unix.rs line 94 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

mod.rs implies that Android and Linux/macOS implement a shared interface for Tun.

// macos and linux
type Tun = imp::UnixTun;
type TunProvider = imp::UnixTunProvider;

// android
type Tun = imp::VpnServiceTun;
type TunProvider = imp::AndroidTunProvider;

But there's nothing that enforces this. 😅

Do you think we could improve this?

Sure, that sounds like a trait to me:)

[dlon]

Reviewed 1 of 4 files at r1.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @MarkusPettersson98)

---

Cargo.lock line 4779 at r1 (raw file):

Previously, MarkusPettersson98 (Markus Pettersson) wrote…

Do you mean in a separate PR? We should probably look at moving to thiserror 2 ourselves, but we will inevitably have both version 1 & 2 in our tree for the foreseeable future:/

Since we can't get rid of version 1 anyway, nevermind. :(

---

talpid-tunnel/src/tun_provider/unix.rs line 94 at r1 (raw file):

Previously, MarkusPettersson98 (Markus Pettersson) wrote…

Sure, that sounds like a trait to me:)

At minimum, I think we should maintain the illusion (return a result on Android too). Don't feel obligated to refactor this more unless you want to.

[MarkusPettersson98]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dlon)

---

Cargo.lock line 4779 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

Since we can't get rid of version 1 anyway, nevermind. :(

://

---

talpid-tunnel/src/tun_provider/unix.rs line 94 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

At minimum, I think we should maintain the illusion (return a result on Android too). Don't feel obligated to refactor this more unless you want to.

Y, I'll mirror the APIs and doing the proper thingy will be left as an exercise for future me:)

[dlon]

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