Fix RLP encoding for types recursively calling RlpStream::append

[maciejhirsz]

Fixes #4356.

[arkpar]

Does this resolve this TODO?

[maciejhirsz]

@arkpar yap, will remove it

[gavofyork]

the changes made seem a little subtle - is there any reason these mistakes won't be repeated in the future?

[maciejhirsz]

@gavofyork there is more insight into it in #4356. In short - there are use cases when calling append inside rlp_append are valid - namely when the type implementing Encodable creates a list with subitems.

The long term solution is to refactor how RlpStream works. I'd suggest that we only ever implement Encodable for non-list types, and do list by generic array / tuple / Iterator impls, to completely avoid the problem of having to count how many items have been appended inside RlpStream.

[rphmeier]

do list by generic array / tuple / Iterator impls

This will be easier said than done as items in RLP lists often have different types. For instance, how would you write a block header as a Vec<T> or Iterator<Item=T>?

[maciejhirsz]

Can use macros to generate generic impl for all tuple sizes up to some limit (20? 32?), such as:

impl<A, B, C, D...> Encodable for (A, B, C, D...) where
    A: Encodable,
    B: Encodable,
    C: Encodable,
    D: Encodable,
    ...
{ ... }