`Encoder::encode_all` calling `flush` makes it incompatible with model chaining in a non-obvious way

[DCNick3]

Encoder::encode_all calls flush after writing all the tokens, which desyncs the bit stream with the decoder if any tokens are written after that.

It can be tempting to use when using model chaining (write some tokens of one type then some of the other), but will desync the decoder when it tries to read it (because decode_all doesn't do any kind of "flush"). Seems that you are aware of that and sidestepped the problem in the concatenated example by using a custom decode function that doesn't flush the stream. I didn't notice this when I was looking at the example, and it took me embarassingly long to debug this.

It seems to me that the root of the issue is that encoder is allowed to write more data after a flush (and there's no way to keep the decoder in sync when doing this).

Some ideas on how this can be improved:

• make flush consume ownership to have compile-time check against this usage or add a runtime check
• clearly document that writing after flush is not to be done
• make a version of encode_all that doesn't flush

[danieleades]

I think there was some obscure reason why i didn't make the flush API consuming but i'll be damned if i can remember what it was.

Definitely worth another look