Redefine TicketSequence as a common field

[mDuo13]

Summary

Relevant source file: TxFormats.cpp

The TicketSequence field of transactions is implemented as a transaction-specific field that is separately added on every type of transaction, but not on pseudo-transactions. This is unnecessarily complexity and may lead to errors later. It should be made a common field instead.

Motivation

It's strange to have one "common field" that is sort-of-technically not one. I believe the original intent was to make sure that pseudo-transactions can never have a TicketSequence, but there's no need to make it not a common field for that to happen; plenty of other common fields also cannot and don't appear in pseudo-transactions.

Meanwhile, having it be not "technically" a common field means that each new transaction type has to have it added. It would be an easy mistake to add a new transaction type and forget to add it. This special case complicates code analysis and documentation. (Currently TicketSequence is documented as if it was a common field, which means people comparing the code to the docs may be confused why it's not listed with the other common fields, and people looking at the transactions' source code may similarly wonder why one of the "specific" fields for that transaction isn't listed as a specific field for that transaction.

Solution

Redefine TicketSequence as a common field of all transaction types.

I am not 100% certain of this, but I believe that with the way transactions' canonical format is defined, this would not change the actual format for any type of transaction that can be submitted; as for pseudo-transactions, it would not meaningfully impact them because those can only be created in the server code that does not use TicketSequence. Therefore, it would not be a transaction processing change and would not require an amendment.

That said, this change would change the order in which fields are added to transaction types in TxFormats.cpp. If for some reason the order matters, then it would be a transaction processing change that needs to be on an amendment (and may not be worth doing).

This can be tested by serializing a transaction with TicketSequence to binary on a server with the code change and one without it; if the two are identical, then it is not a transaction processing change. (Maybe, to be sure, it should be on a transaction type that defines a field after TicketSequence and should use that field. That would be an AccountSet with NFTokenMinter or an AMMDeposit with TradingFee.)

[mDuo13]

EDIT: I just discovered that this has already been (sorta) done in the develop branch by #4637. (I was looking at master.) I believe we can safely remove the macro to separate "common fields" for pseudo- and non-pseudo transactions.