optimize to reduce a perf regression with go-merkledag

[mvdan]

We're switching go-merkledag from its ancient protoc-gen-gogo encoder-decoder to this codec.

The good news is that it works well :) The bad news is that the new branch is about twice as slow when encoding and decoding a ProtoNode, what we can call a "roundtrip".

It's fair to say that part of the blame is to be put on go-merkledag itself, as it has to translate between ProtoNode and PBNode. Still, a good chunk of the slowness was coming from the codec itself.

This pull request includes all the optimizations made to the codec itself. The benchmark will live in go-merkledag once we can merge to master in a week or two. There are gaps between the numbers here because those gaps were optimizations in go-merkledag directly.

Once this is merged, I can push the optimizations to go-merkledag's ipld-in-ipfs branch. I need to do that in order, because otherwise I'd have the go-merkledag branch depend on a non-master branch of dagpb.

Please see the commit messages, which contain benchmark numbers and deatils. I care more about those than I do about this PR body message, so please don't squash-merge :)

[mvdan]

Also FYI @warpfork, in case you were wondering where the codec's slowness was coming from.

I think having generic codec interfaces be Reader/Writer is fine, but it should also be fine for lower-level shortcuts like these for use cases like go-merkledag.

[mvdan]

Also, I realise this pulls in protowire and the google.golang.org/protobuf module, but I think that should be fine:

• The protowire package itself has few deps, and is pretty small
• It would take us at least a week of effort to write protowire-like funcs that are so well optimized and tested
• It's reasonable for a protobuf codec to... require the protobuf module :)
• It's likely that any program using dagpb will end up requiring the protobuf module anyway

[mvdan]

Also, to give a high-level view, this is the 2x slow-down between go-merkledag master and our first go-codec-dagpb implementation:

name         old time/op    new time/op    delta
Roundtrip-8    3.24µs ± 3%    6.49µs ± 1%  +100.40%  (p=0.002 n=6+6)

name         old alloc/op   new alloc/op   delta
Roundtrip-8    4.94kB ± 0%    8.07kB ± 0%   +63.27%  (p=0.002 n=6+6)

name         old allocs/op  new allocs/op  delta
Roundtrip-8       109 ± 0%       171 ± 0%   +56.88%  (p=0.002 n=6+6)

With the help of these patches, we're down to a 1.25x slow-down:

name         old time/op    new time/op    delta
Roundtrip-8    3.24µs ± 3%    4.07µs ± 0%  +25.72%  (p=0.002 n=6+6)

name         old alloc/op   new alloc/op   delta
Roundtrip-8    4.94kB ± 0%    6.38kB ± 0%  +29.13%  (p=0.002 n=6+6)

name         old allocs/op  new allocs/op  delta
Roundtrip-8       109 ± 0%       103 ± 0%   -5.50%  (p=0.002 n=6+6)

[hannahhoward]

LGTM by me :)