Initial implementation

[oxtoacart]

No description provided.

[oxtoacart]

I've tried running the unit test on Travis and Wercker, and neither support creating a TUN device. The problem is that they (and Circle CI) run unprivileged docker containers for security reasons, and such containers don't have access to /dev/net/tun.

[oxtoacart]

@hwh33 I've pushed updates that address your insightful code review comments.

[hwh33]

Would you mind explaining why we use ops.Go to spawn goroutines? I looked at the package a bit and it looks like it's adding context to the goroutines. That context looks useful, but how is it actually used? Is it logged somewhere? Or accessible to and used by the goroutines somehow?

Also thanks for the patience with all the questions on this PR haha

[oxtoacart]

Would you mind explaining why we use ops.Go to spawn goroutines?

golog reports the context associated with the current goroutine when it logs. The same context is also included when we report to borda.

For example, here's a log seen while running Lantern:

May 24 13:09:32.754 - 0m3s DEBUG balancer: balancer.go:355 Successfully dialed via fp-donyc3u16-20190523-138 (142.93.178.69:443) to connect://borda.lantern.io:443 on pass 0 (52.953949ms) [beam=37 local_proxy_type=http op=balancer_dial_details origin=borda.lantern.io:443 origin_host=borda.lantern.io origin_port=443 remotely_proxied=true root_op=proxy user_agent=Go-http-client/1.1]

All those key=value pairs in square brackets are the context.

[oxtoacart]

Also thanks for the patience with all the questions on this PR haha

Thanks for the thorough review!

[hwh33]

LGTM!

Thank you for the explanation of ops.Go and the use of the context. That's helpful, especially with the example.

[oxtoacart]

Thanks for the thorough review!