Recognize "0" as a legacy transaction type in serializeTransaction

[smartcontracts]

Describe the bug
Infura (and perhaps others?) seems to attach type: 0 to transactions that don't have a type. This might just be a geth behavior but I haven't bothered to check. I wanted to serialize one of these transactions with ethers.utils.serializeTransaction, but I got the following error:

{ Error: unsupported transaction type: 0 (operation="serializeTransaction", transactionType=0, code=UNSUPPORTED_OPERATION, version=transactions/5.1.1)
    ...
  reason: 'unsupported transaction type: 0',
  code: 'UNSUPPORTED_OPERATION',
  operation: 'serializeTransaction',
  transactionType: 0 }

Seems the source of the error is this check which assumes transactions will have type: null instead of type: 0. Easily fixable for now by setting transaction.type = null but I figure you should be aware of this behavior.

Reproduction steps

const ethers = require('ethers')

const main = async () => {
  const endpoint = 'https://mainnet.infura.io/v3/whatever'
  const provider = new ethers.providers.JsonRpcProvider(endpoint)
  
  const block = await provider.getBlockWithTransactions(46147)
  const transaction = block.transactions[0]
  console.log(ethers.utils.serializeTransaction({
    type: transaction.type,
    chainId: transaction.chainId,
    nonce: transaction.nonce,
    gasPrice: transaction.gasPrice,
    gasLimit: transaction.gasLimit,
    to: transaction.to,
    value: transaction.value,
    data: transaction.data
  })) // Error!
}

main()

Environment:
Node v14.15.1
Query against infura

[smartcontracts]

Hmmm after digging a little further it seems like I'm not supposed to be using null at all -- I'm actually supposed to be using undefined. Using null will trigger a failure here:

ethers.js/packages/transactions/src.ts/index.ts

Line 174 in 4898e7b

checkProperties(transaction, allowedTransactionKeys);

. Needs to be undefined which will still pass because undefined == null.

[ricmoo]

This is intentional; you should not use type 0, as it is not actually reserved in the EIP (so theoretically you could have a future transaction envelope version 0 which has some other behaviour). I've asked as well for type 0x19 to be reserved, but the EIP authors would prefer that be moved to some other registry. But for now, I think it is safe to assume 0x00 and 0x19 are considered reserved from an application point of view, but that isn't safe at the library level.

For your purposes, you should probably use null, but if your project has the TypeScript flag strict configured, you will need to use undefined (either will work, but I had intended for people to use null). In v6, the library will be in strict mode so the type will be null | BigNumberish, but for v5 non-strict is assumed.

You could do something like type: (transaction.type || undefined) which will trap null, 0 or any other falsy value and set it to undefined, which will match the TypeScript signature, even in the case of strict.