[Raft] Consensus entries publishing and proposal

[MariemBaccari]

Completes the consensus business logic implementation from #1473 by adding the entries publishing logic and the Execute method which will be used by the Store to commit entries to Raft.

We defined a Raft proposal as:

type Proposal struct {
	ID          string    `json:"id"`
	NodeID      uint64    `json:"node_id"`
	Timestamp   time.Time `json:"timestamp"`
	RequestType string    `json:"request_type"`
	Value       []byte    `json:"value"`
	// ReadOnly proposals do not modify the state machine and,
	// therefore, do not need to be applied by nodes who did not initiate them.
	// TODO: This is a temporary solution. In the future, we will use ReadIndex
	// for read-only operations without needing to propose them to Raft.
	ReadOnly bool `json:"read_only"`
}

• ID is a globally unique identifier (UUID) to keep track of the proposal when it comes back as a committed entry.
• NodeID the Raft node ID of the current DSS node.
• Timestamp is defined by the proposing node and ensures time-dependent operations execute deterministically across nodes and replays .
• RequestType is the type of the request (e.g. DeleteSubscription).
• Value is the proposal payload (i.e. a serialized representation of an ASTM API operation).
• ReadOnly proposals are currently processed the same as ReadWrite operations. They go through Raft as a proposal to ensure serializability. In the future, we will use ReadIndex to maintain these guarantees while avoiding the consensus round.

[the-glu]

LGTM

[barroco]

Partital review. Please consider the comments

[barroco]

Partial review 3

[barroco]

Partial review 4