Proto: Send tickets for implicit->originated directly via [Transaction] (behind feature flag)

Closes #2924 (closed)

Part of milestone %Direct ticket transfer from implicit to originated

Addresses first item from Michael Zaikin's proposal: https://hackmd.io/@m-kus/BJsQS4kJT

Builds upon !10432 (closed)

Implementation notes

The main challenge comes from typing the provided parameter, which is required to detect tickets in the parameter. In theory, typing should be possible, as the contract on the receiving end retains the type information. However, the typing of the parameter was performed downstream in the pipeline, so we had to shift the typing process to an earlier stage in the pipeline, specifically within the apply function.

Important follow-ups

Several important follow-ups need to be addressed before enabling the feature flag:

1. We must set allow_forged to true to allow tickets to appear in the parameter from implicit, but also enables placing lazy storage ids in the parameter, which is something we should avoid.
   • Can be addressed by splitting allow_forged into something like allow_tickets and allow_lazy_storage_id: #2964 (closed)
2. Consider the security implications. Users cannot know they are transferring tickets by just inspecting parameters, which look like Pair 0x01fb.. (Pair "foo" 1). This means they can be tricked into sending tickets without knowing.
   • Introduce a new Ticket primitive so ticks appear as tickets in the Micheline expression? #6643 (closed)
3. Merge items with same ticket token in ticket receipt: #6639

Manually testing the MR

Here is the regression output for the transfer:

./octez-client --wait none transfer 0 from bootstrap1 to '[CONTRACT_HASH]' --burn-cap 1 --entrypoint save --arg 'Pair 0x01fb08747351ab3652f772910c4565880d8df616f800 (Pair "Ticket" 1)'
Node is bootstrapped.
Estimated gas: 3076.305 units (will add 100 for safety)
Estimated storage: 44 bytes added (will add 20 for safety)
Operation successfully injected in the node.
Operation hash is '[OPERATION_HASH]'
NOT waiting for the operation to be included.
Use command
  octez-client wait for [OPERATION_HASH] to be included --confirmations 1 --branch [BLOCK_HASH]
and/or an external block explorer to make sure that it has been included.
This sequence of operations was run:
  Manager signed operations:
    From: [PUBLIC_KEY_HASH]
    Fee to the baker: ꜩ0.00062
    Expected counter: 4
    Gas limit: 3177
    Storage limit: 64 bytes
    Balance updates:
      [PUBLIC_KEY_HASH] ... -ꜩ0.00062
      payload fees(the block proposer) ....... +ꜩ0.00062
    Transaction:
      Amount: ꜩ0
      From: [PUBLIC_KEY_HASH]
      To: [CONTRACT_HASH]
      Entrypoint: save
      Parameter: (Pair 0x01fb08747351ab3652f772910c4565880d8df616f800 (Pair "Ticket" 1))
      This transaction was successfully applied
      Updated storage:
        { Pair 0x01fb08747351ab3652f772910c4565880d8df616f800 (Pair "Ticket" 1) }
      Storage size: 238 bytes
      Paid storage size diff: 44 bytes
      Consumed gas: 3076.239
      Balance updates:
        [PUBLIC_KEY_HASH] ... -ꜩ0.011
        storage fees ........................... +ꜩ0.011
      Ticket updates:
        Ticketer: [CONTRACT_HASH]
        Content type: string
        Content: "Ticket"
        Account updates:
          [PUBLIC_KEY_HASH] ... -1
        Ticketer: [CONTRACT_HASH]
        Content type: string
        Content: "Ticket"
        Account updates:
          [CONTRACT_HASH] ... +1

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