Message index/count refactor - Part 1

[diegoximenes]

Resolve NIT-2569

Different parts of Nitro (TransactionStreamer, InboxTracker, ExecutionEngine, Broadcaster, BlockValidator, etc), need to access the number of messages, or the content of a message, or the result related to processing a message.
Those properties are accessed in different ways through Nitro's code base, decreasing code readability.
Examples:

• In order to get the result related to processing a message, BlockValidator calls TransactionStreamer.ResultAtCount passing the message index plus one. However, in order to get the result related to processing a message, TransactionStreamer calls ExecutionEngine.ResutlAtPos passing the message index as argument.
• Variables that identify a message are named differently across the code base, such as pos, num, seq, index.

While reading the code base it is not uncommon to confuse what is the semantic meaning of a variable, such as if it is holding the number of messages, or a message identifier.

This PR is the first part of a refactor that unifies how properties related to messages are accessed through Nitro.
This PR mainly focus on refactoring TransactionStreamer, ExecutionEngine and Broadcaster.
It decreases message count usage in favor of using message indexes, such as declaring func (n *ExecutionNode) Reorg(newHeadMsgIdx arbutil.MessageIndex, ..., instead of func (n *ExecutionNode) Reorg(count arbutil.MessageIndex, ....
It names message indexes identifiers as msgIdx.

If the approach of this PR is approved, then later more PRs are going to be created with the following goals:

• Spread the same approach to InboxTracker, BlockValidator, etc.
• Create a arbutil.MessageCount type, as uint64. In this way it will be easier to identify the semantic meaning of a variable.
• Represent delayed messages indexes as arbutil.MessageIndex.

[Tristan-Wilson]

What do you think about having a single type that represents the position which is what you pass around, and then having accessors for .Index() and .Count()?

You could even wrap it like this so you don't accidentally do some illegal operation with it.

type MessageIndex struct {
  inner uint64
}

I'm interested to hear others' thoughts too on this part of the PR since it's the core of the design.

[diegoximenes]

But what is the meaning of .Count()?
Is it the current length of the messages container, the length of the messages container that the caller expects, or just .Index() + 1?

[tsahee]

initial thoughts