Fix: move type flag encoding back into encode_2718

[prestwich]

it looks like d0794e5 lightly broke eip2718 abstraction by making type flags tx-associated instead of envelope-associated. We would now behave badly for networks where the type flag is different (e.g. TxEip1559 is flag 17, or where both 4 and 5 are TxEip7702

It also means that if we have a tx type with two different on different networks, they can't re-use the same codepaths

Need to move the flag encoding back into the envelope-level encode_2718 implementation

Originally posted by @prestwich in #1460 (comment)

[prestwich]

cc @Rjected

[prestwich]

this also affects encode_for_signing in SignableTransaction, which somewhat implies we need to re-think the signing trait model 😮‍💨

[klkvr]

We would now behave badly for networks where the type flag is different (e.g. TxEip1559 is flag 17, or where both 4 and 5 are TxEip7702

I am not sure we should optimize for this edge case at cost of forcing users to route all encoding through envelope and introducing additional layering on envelope variants

[prestwich]

I am not sure we should optimize for this edge case at cost of forcing users to route all encoding through envelope

The 2718 edge case aside, we already force users to route encoding through envelope, it was one of the main goals of introducing it as a type and the only reason for making all the encoding methods hidden in #529. There was a lot of discussion on this in issues and the telegram group at the time and we collectively agreed that running coding via the transaction types has proven to result in bad user behavior

Basically, from ethers we learned we can't rely on users to understand the distinction between eip2718, rlp, and network format. As a result, having those be a public API is a footgun for users. We saw this a lot with users RLP encoding 1559 transactions to submit to sendRawTransaction, which failed and resulted in an awful lot of confused messages in telegram. Making incorrect or confusing actions inaccessible to users was a primary goal of introducing the envelope type in the first place

[prestwich]

closing in favor of solution in #1496