Proto: Catch pogs panic

[oncilla]

Catch panics when deserializing capnp messages using pogs.
This could happen on malformed input, see capnproto/go-capnp#137

This change is 

[lukedirtwalker]

Please add a comment to the upstream issue (capnproto/go-capnp#137) in the commit message and in the code. I guess normally we shouldn't expect the library to panic?
So once this is fixed upstream can we remove this patch again?

Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @scrye)

[oncilla]

I think the catching the panic is actually the right thing to do, even when the issue is fixed.

Our services should not panic because of malformed input.
Sure, panics should not cross package boundaries as per go convention. However, as this has shown, we cannot always rely on this.

I feel a lot more comfortable if we have a recover after calls to libraries that handle tainted input.

Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @scrye)

[scrye]

I would keep the recover code, just to minimize risk of services crashing. Otherwise we need to perform a fuzzing check (which might be incomplete) every time we change the commit.

(Also related, historically we did not deploy adapters/API regression tests on top of third-party libraries, but cases like this show why in some cases it is useful to have them, especially for very complex libraries that deal with encoding/decoding).

Reviewable status: 0 of 1 files reviewed, all discussions resolved (waiting on @scrye)

[scrye]

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