Use go 1.11 module versioning support

[boklm]

Go 1.11 is adding preliminary support for Go modules, replacing the GOPATH-based approach.

obfs4 is adding go.mod and go.sum files, which use the Go modules support to fetch the dependencies. We disable that in #28310 as the go libraries we build are not currently recognized as Go modules.

We should change how we build our Go libraries so that they can be used as Go modules.

[cohosh]

We could really use this for the snowflake reproducible build. Our solution to the Windows build issue is to use a different webrtc library (which will probably be less painful for us down the road anyway). However, that library has 30+ dependencies and is a pain to build right now (see https://trac.torproject.org/projects/tor/ticket/28942#comment:39).

Is this item roadmapped or is there some information on how difficult this task would be?

[gk]

Replying to cohosh:

We could really use this for the snowflake reproducible build. Our solution to the Windows build issue is to use a different webrtc library (which will probably be less painful for us down the road anyway). However, that library has 30+ dependencies and is a pain to build right now (see https://trac.torproject.org/projects/tor/ticket/28942#comment:39).

Is this item roadmapped or is there some information on how difficult this task would be?

It's not roadmapped as we did not have any prio to do this so far. Not sure how difficult it would be but my guess it not too difficult. Is that ticket blocking you? Or, asked differently: by when would you need this solved?

[cypherpunks]

​https://blog.golang.org/migrating-to-go-modules

[cohosh]

Replying to gk:

Replying to cohosh:

We could really use this for the snowflake reproducible build. Our solution to the Windows build issue is to use a different webrtc library (which will probably be less painful for us down the road anyway). However, that library has 30+ dependencies and is a pain to build right now (see https://trac.torproject.org/projects/tor/ticket/28942#comment:39).

Is this item roadmapped or is there some information on how difficult this task would be?

It's not roadmapped as we did not have any prio to do this so far. Not sure how difficult it would be but my guess it not too difficult. Is that ticket blocking you? Or, asked differently: by when would you need this solved?

I'm still unfamiliar with what exactly we need for reproducible builds. If all we need is a commit hash for every go library that snowflake depends on, I could probably spend a day or two writing a messy build script for the pion go version of snowflake. It's annoying but doable.

I think the pion version is becoming more and more necessary given #31446 and us wanting to roll out support for windows users. So my answer is: if a hacky build script as described above would work, it's not necessary. If not, then we are blocked on this for moving away from the messy chromium webrtc sources.

[boklm]

I am still not sure how we should support fetching of sources for go modules in our build. In order to not block progress on using pion, if it has too many dependencies to manually create one project for each dependency, I think an other option is to run go mod vendor to fetch all dependencies, create a tarball of the vendor directory it created, then put the tarball online somewhere and use it as a dependency for the pion build.

[gk]

Let's pick this up for November/December.

[pili]

Assigning tickets to boklm for the next few months

[boklm]

It seems this issue is similar to #31588.

One option to fix this would be to add a special build step where we allow network access in the container, and run go mod vendor and create a vendor tarball that we later use in the build.

[pili]

Moving tickets to December