Reduced `max_operations_ttl` to fix Parisnet Operation Injections

[igorsereda]

This PR fixes errors like

pytezos.rpc.node.RpcError: ({'id': 'failure',
  'kind': 'temporary',
  'msg': 'Operation ooRp9PH8nTAhdn2zyL5P9FyoFKgdfbV25R8YbnnEYvxxRz3c6vd is '
         'branched on either:\n'
         ' - a block BLM7z6yUZCZMzWEnFzsgRbTzfTev5m35Mf9CCXeBLuJTxu5LGtE which '
         'is too old (121 blocks in the past)\n'
         ' - a predecessor block from an alternative branch which is now '
         'unknown'},)

[github-actions[bot]]

Test Results

1 110 tests  ±0   1 098 :white_check_mark: ±0   1m 45s :stopwatch: -19s     4 suites ±0      12 :zzz: ±0      4 files   ±0       0 :x: ±0 

Results for commit ddee28ab. ± Comparison against base commit 85a7ce83.

[github-actions[bot]]

Test Results

1 110 tests  ±0   1 098 :white_check_mark: ±0   2m 5s :stopwatch: -1s     4 suites ±0      12 :zzz: ±0      4 files   ±0       0 :x: ±0 

Results for commit ddee28ab. ± Comparison against base commit 85a7ce83.

:recycle: This comment has been updated with latest results.

[ztepler]

I tried to understand what was happening here and why this constant affects transactions at all.

As far as I understand, this MAX_OPERATIONS_TTL is used to calculate the branch here. As far as DEFAULT_OPERATIONS_TTL is 5 the branch will be equal to the head~115 block hash. And then the OperationGroup spawned with this branch, right?

Not sure why this logic is required, why not use more recent blocks?

I suppose this is because before Tenderbake (about two years ago) there was no finality and there was a chance that the chain would be forked, can someone confirm?

Anyway, I checked that this works both in the pariscnet and mainnet, so looks good to me.