node/ref: Encode message finalization status in message type

[tbjump]

Issue
It is somewhat cumbersome to audit the different steps involved between a message being first observed on chain, to it being finalized on-chain, passing accounting and governor, and finally being signed by the guardian. This is further complicated by the additional code paths for re-observations and persisting state on storage between guardian restarts.

Idea
I propose the following naming convention for the different finalization states of a message:

1. Unfinalized: The message has been observed somewhere, but the Guardian has not confirmed that it has been finalized on the origin chain.
2. Finalized: The message has been finalized on the origin chain.
3. Approved: The message has passed Governor and Global Accountant and is ready to be signed by the Guardian.

I am wondering if it would make the code more readable if there were different types for a message depending on what its finalization status is. That way the type system could enforce that e.g. only Approved messages can be signed and the state transitions become more explicit.

It could look like this in chainlock.go:

type (
	UnfinalizedMessage struct {
		messagePublication
	}

	FinalizedMessage struct {
		messagePublication
	}

	ApprovedMessage struct {
		messagePublication
	}
)

type messagePublication struct {
	TxHash common.Hash // Transaction hash of the transaction that emitted this message. Included for observability. TODO: rename to identifier? on Solana, this isn't actually the tx hash

	// Observation
	Timestamp        time.Time
	Nonce            uint32
	Sequence         uint64
	ConsistencyLevel uint8
	EmitterChain     vaa.ChainID
	EmitterAddress   vaa.Address
	Payload          []byte

	// Unreliable indicates if this message can be reobserved. If a message is considered unreliable it cannot be
	// reobserved.
	Unreliable bool
}

This change would touch many different files.

What do y'all think?

[SEJeff]

It moves a lot of code around, but does make it more intuitive for auditing and general maintenance. It's somewhat of a shame we don't use an existing state machine library like looplabs/fsm which has native support for turning the state flows into dot files or svgs. Being able to visualize this from the code directly would be hugely useful for someone new to the codebase.