Baker: Make record_state function optional

Context

Closes #6493 (closed).

The record_state was doing the following (time costly) things:

• obtain the wallet's mutex
• binary encode state data (level, round, payload)
• perform I/Os to write to a record_state file

Under normal conditions, during a consensus round, this state saving is performed once so the theoretical gain is estimated to be the average value: 91.6ms. There are also some additional gains due to concurrency that are hard to estimate as it depends on disk I/Os and other components relying on the wallet's lockfile mechanism.

We introduce a record-state flag for protocols Nairobi, Oxford and Alpha.

./octez-baker-<protocol> run with local node ... --record-state

When the option is not set, the default is false. We do this so that we can opt out of recording the state, since in the profiling results we could observe that unnecessary long time was spent:

perform action 'inject endorsements' ......................................... 1          227.734ms  37% +8s35.355ms
  record state ............................................................... 1           94.392ms  23% +0.002ms
    waiting lock ............................................................. 1            0.051ms 100% +0.010ms
    serializing baking state ................................................. 1            4.473ms 100% +0.062ms
    writing baking state ..................................................... 1           89.651ms  18% +4.538ms
    renaming file ............................................................ 1            0.191ms  96% +94.191ms
  inject endorsements ........................................................ 1          133.194ms  48% +94.396ms

Manually testing the MR

dune exec tezt/tests/main.exe -- --file baker_operations_cli_options.ml

After running an experiment with @andrea.cerone using this change, we could see in the baker_profiling.txt file that the record state part was indeed missing (we could usually find it after the perform action 'inject endorsements' part:

perform action 'inject endorsements' ......................................... 1          212.159ms  14% +2s811.634ms
  inject endorsements ........................................................ 1          212.015ms  14% +0.001ms
    sign endorsements ........................................................ 1           55.984ms  25% +0.000ms
  ...

Checklist

• Document the interface of any function added or modified (see the coding guidelines)
• Document any change to the user interface, including configuration parameters (see node configuration)
• Provide automatic testing (see the testing guide).
• For new features and bug fixes, add an item in the appropriate changelog (docs/protocols/alpha.rst for the protocol and the environment, CHANGES.rst at the root of the repository for everything else).
• Select suitable reviewers using the Reviewers field below.
• Select as Assignee the next person who should take action on that MR