mod codec improvements

[tgeoghegan]

In #252, we discuss the notion of providing mod codec separately from prio. Elsewhere, @cjpatton has been thinking about improvements to mod codec to make it more ergonomic and efficient (cloudflare/daphne#15). Now that we have some implementation experience under our belts, we should design and implement a faster and friendlier mod codec, and consider shipping it to crates.io separately from prio.

[cjpatton]

I'd be happy to help out!

[cjpatton]

@divergentdave, @tgeoghegan, @inahga do we still have appetite to improve the codec traits? Now would be a good time I think cc @mendess

[mendess]

Having the codec traits in the same crate as the rest of prio has caused some problems for when trying to support two versions of prio to make transition better.

The problem is that parts of prio require types that implement the traits in codec, but when the major version of the prio crate is bumped, this also "bumps" the version of the traits, even if they didn't change, which causes the compiler to consider these different traits.

What we end up having to do is implement the same trait N times where N is the number of prio versions we want to support.

If the codec traits, which have been quite stable for some time now, were in a separate crate this issue would be minimized in the future

[tgeoghegan]

The argument for kicking the codec module out of prio was that it leaks a DAP-layer concern (wire encoding of DAP protocol messages) into prio, which is intended to be an implementation of VDAF. However at this point, VDAF specifies the encoding a variety of messages in TLS syntax, which weakens that argument. Nonetheless, I think having mod codec be independent would be nice. That crate would also become a natural place to implement Serde traits for TLS syntax, which could be useful to all sorts of people. If it helps makes something easier for Daphne, then even bette.r

However, I don't think it should be a design goal for prio to support running multiple versions in a single compiled target, because I don't know what kind of testing or validation we would do to ensure we maintain that guarantee across future changes. This project's stance is that if you need to run multiple versions of VDAF, you should maintain multiple branches of your application and have each pull in the appropriate version of crate prio.