Check the validity of the given operation; return an updated validate_operation_state, and a stamp attesting that the operation has been validated.
An operation is valid if it may be included in a block without causing the block's application to fail. The purpose of this function is to decide validity quickly, that is, without trying to actually apply the operation (ie. compute modifications to the context: see Apply.apply_operation) and see whether it causes an error.
An operation's validity may be checked in different situations: when we receive a block from a peer or we are constructing a fresh block, we validate each operation in the block right before trying to apply it; when a mempool receives an operation, it validates it to decide whether the operation should be propagated (note that for now, this only holds for manager operations, since validate_operation is not impleted yet for other operations: see below). See mode.
The validate_operation_info contains every information we need about the status of the chain to validate an operation, notably the context (of type Alpha_context.t) at the end of the previous block. This context is never updated by the validation of operations, since validation is separate from application. Yet sometimes, the presence of some previous operations in a block or a mempool may render the current operation invalid. E.g. the one-operation-per-manager-per-block restriction (1M) states that a block is invalid if it contains two separate operations from the same manager; therefore the validation of an operation will return Error Manager_restriction if another operation by the same manager has already been validated in the same block or mempool. In order to track this kind of operation incompatibilities, we use a validate_operation_state with minimal information that gets updated during validation.
For a manager operation, validity is solvability, ie. it must be well-formed, and we need to be able to take its fees. Indeed, this is sufficient for the safe inclusion of the operation in a block: even if there is an error during the subsequent application of the manager operation, this will cause the operation to have no further effects, but won't impact the success of the block's application. The solvability of a manager operation notably includes it being correctly signed: indeed, we can't take anything from a manager without having checked their signature.
TODO: https://gitlab.com/tezos/tezos/-/issues/2603
This function currently does nothing for non-manager operations (instead, the validity of a non-manager operation is decided by calling Apply.apply_operation to check whether it returns an error). We should specify and implement the validation of every kind of operation.