Kicking the tires downstream

I have been experimenting in the bip324 library with writing sans-io code which finds a good balance between flexibility, maintainability, performance, and ergonomics. It has been an educational struggle. But it appears that `push_decode` might wrap up that complexity nicely, and fills the niche well vs. some super complex parsing library. So I am pretty interested in its adoption. I wrote a small test library over here, [bitcoin-codecs](https://github.com/nyonson/bitcoin-codecs/blob/master/src/lib.rs), which uses `push_decode` to define bitcoin's v1 transport decoding. Even though the internal message contents still delegates to the std I/O bound `bitcoin::io` crate, I think this would be a nice addition to the newly minted [p2p](https://github.com/rust-bitcoin/rust-bitcoin/tree/master/p2p) crate, and a way to kick the tires on `push_decode`. I'd love some feedback on my general usage so far. I am still circling on two things in particular.

The first is if the codec crate is appropriately using the `then` combinator (header + payload under the hood), or if it should be using `sub_decode`?

The second is caller ergonomics. This codec crate could just export the decoder (`V1MessageDecoder`) and leave it up to the calling crate to depend on `push_decode` as well and pull in the I/O driver of their choice. But is that a little clunky? Or a bit much to ask of the caller to be aware of this crate? The codec crate could also map some feature flags 1:1 with `push_codec`'s and add some glue code. I am thinking like a simple wrapper which takes a reader and calls `decode_*_with` with a decoder under the hood. Is there a best practice pattern for this?

Start with bitcoin-codecs/src/lib.rs and the p2p crate's transport-decoding entry points, then read the push_decode documentation for the then and sub_decode combinators and the decode_*_with APIs. The issue is complete only after the maintainers agree on the decoder composition and caller-facing integration pattern.

Written by the indexing model from the issue text.