introduce1: we need an encoded form of the (unencrypted) header to generate the encrypted portion.

This is insufficiently specified, but the MAC in the encrypted part of an INTRODUCE[12] message appears to cover not only the encrypted portion, but also the unencrypted headers (LEGACY_KEY_ID through EXT_FIELDS). This means that:

• when we are generating an INTRODUCE1 message, we need to first generate and encode its header before we can encrypt its body.
• When we receive an INTRODUCE2 message, we need a slice-ish view of its header in order to decrypt its body.

So it appears we need another refactoring of the Introduce message types. I hope this might be the last?