Use Shadowsocks library instead of launching a subprocess

[dlon]

This updates the Shadowsocks proxy monitor to use the crates instead of launching a subprocess, and removes all related binaries and references to them. It also contains some refactoring of the OpenVPN monitor.

Related PR: mullvad/mullvadvpn-app-binaries#93

---

This change is 

[pinkisemils]

Reviewed 10 of 14 files at r1, all commit messages.
Reviewable status: 10 of 14 files reviewed, all discussions resolved

[dlon]

Reviewable status: 9 of 14 files reviewed, 1 unresolved discussion (waiting on @pinkisemils)

---

talpid-core/src/tunnel/openvpn/mod.rs, line 318 at r1 (raw file):

        let handle = runtime.handle().clone();
        handle.block_on(Self::new_internal_with_runtime(

This seems sketchy in retrospect: runtime_handle.block_on(f(runtime)). This task itself will still exist when the runtime is dropped. It works, but it could be cleaner.

I think we should have a TunnelMonitor trait with async start and wait methods. But I don't want to make a bunch of unrelated changes here.

[pinkisemils]

Reviewed all commit messages.
Reviewable status: 9 of 14 files reviewed, 1 unresolved discussion (waiting on @pinkisemils)

[pinkisemils]

Reviewed 1 of 14 files at r1.
Reviewable status: 10 of 14 files reviewed, 2 unresolved discussions (waiting on @dlon and @pinkisemils)

---

talpid-core/src/tunnel/mod.rs, line 160 at r3 (raw file):

                    match proxy {
                        openvpn_types::ProxySettings::Shadowsocks(..) => {
                            return std::env::current_exe().unwrap()

Is this necessary on anything besides Windows? It's still good to have this interface, but if I understand this correctly, the only reason the path for the path to exist is to let the firewall exclude the traffic, right?

[dlon]

Reviewable status: 10 of 14 files reviewed, 2 unresolved discussions (waiting on @pinkisemils)

---

talpid-core/src/tunnel/mod.rs, line 160 at r3 (raw file):

Previously, pinkisemils (Emīls Piņķis) wrote…

Is this necessary on anything besides Windows? It's still good to have this interface, but if I understand this correctly, the only reason the path for the path to exist is to let the firewall exclude the traffic, right?

What changes are you proposing? This is still needed to decide whether openvpn.exe or mullvad-daemon.exe should be allowed to talk to the first hop.

[pinkisemils]

Reviewed 2 of 14 files at r1, 2 of 2 files at r3.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @dlon)

---

talpid-core/src/tunnel/mod.rs, line 160 at r3 (raw file):

Previously, dlon (David Lönnhager) wrote…

What changes are you proposing? This is still needed to decide whether openvpn.exe or mullvad-daemon.exe should be allowed to talk to the first hop.

Since it's still useful, then I propose that the current code is plenty good enough.

---

talpid-core/src/tunnel/openvpn/mod.rs, line 318 at r1 (raw file):

Previously, dlon (David Lönnhager) wrote…

This seems sketchy in retrospect: runtime_handle.block_on(f(runtime)). This task itself will still exist when the runtime is dropped. It works, but it could be cleaner.

I think we should have a TunnelMonitor trait with async start and wait methods. But I don't want to make a bunch of unrelated changes here.

Making it async would be better.

[pinkisemils]

Reviewable status: complete! all files reviewed, all discussions resolved

[pinkisemils]

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

[dlon]

Reviewable status: 12 of 14 files reviewed, all discussions resolved (waiting on @pinkisemils)

---

talpid-core/src/tunnel/openvpn/mod.rs, line 318 at r1 (raw file):

Previously, pinkisemils (Emīls Piņķis) wrote…

Making it async would be better.

Done. I've removed the runtime. This could still be improved, but I'll leave that for another PR.

[pinkisemils]

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