Update gogo protobuf dependency

[whyrusleeping]

We havent updated our gogo-protobuf dep in a while. The primary reason for this is that its not as simple to do as a lot of our other deps. The repo itself is huge, and our current gogo-protobuf package is roughly 40MB. This make the gx install ux slow and really annoying.

We should look at repackaging a newer version with exactly what we need, or finding a better way to shrink this package to just what we need to make the process of keeping things updated easier.

cc @Kubuxu @parkan @vyzo

[vyzo]

This has escalated into a serious problem for us, because the vendored gogo-protobuf apparently generates code that can't marshall/unmarshall oneofs.

Is there any workaround with gx to make it not rewrite the gogo-protobuf dependency in our tree? We don't explicitly depend on the gx vendored package, but it gets rewritten because of the transitive dependency through libp2p.

[Kubuxu]

The huge part of gogo-protobuf are tests (there is tests that has 400k lines). We could add them to .gxingnore.

[Kubuxu]

Also it looks like we are using only /proto and /io.

[Kubuxu]

Removing /test form the gx export will leave us with about 1MiB code package.

[Kubuxu]

@vyzo you can try importing QmVsHZSaohNEZrzNuBPi9z63iiJxWc2rvN4PZKqJXQ9oU5 which is current master of gogo/protobuf but I have no idea how it will work (there might be backward incompatible changes).

[vyzo]

@Kubuxu thanks, the explicit import of this new version works with protos compiled with unvendored gogo-protobuf!

[vyzo]

And needless to say, it solves our marshaling woes :)

[Kubuxu]

The process became just a bit more complicated, as gogo protobuf fixed bug with order of values.

Version of protobuf used by us includes the bug, current protobuf 3 version is fixed.

Meaning that if we update the protobuf library hashes of new files will change.

[Kubuxu]

gogo/protobuf#42

[ribasushi]

Was browsing around and ran across this issue.

Since you are about start producing new hashes anyway ( due to the different order of protobuf "frames" ) may I suggest re-declaring repeated varint fields as packed? According to the spec packed fields are forward and backward compatible...

This will save 1~2 bytes per unixfs link (and likely for other higher protocols too)

[Kubuxu]

We won't be changing output hashes just to update protobuf Also as far as I know, we won't be touching protobuf-unixfs format. We plan deprecating it, and maybe creating ipld-unixfs in version 0.5 but it isn't still decided, AFAIK.

@whyrusleeping might know more about this.