These are just development notes.

* Some protocols/stacks will look into the data even before the packet is CRC'ed. This can be the case both for
  the BLE header & the 802.15.4 "header" (actual phy payload).
  Today the Phy provides an uncorrupted packet, so the device cannot directly behave like if it received the possibly corrupted one, and be fully correct.
  Some protocols will check the header (in SW or HW), but also may have FEC in this headers.
  
  Today the options for the device are to either
   * or to assume no errors while doing the ongoing packet parsing, and have a too good performance (only react to the CRC errors eventually discarding the payload)
   * when the phy says that either the header or payload is corrupted, always assume the erros in the some places (say in the worst case place)
   * or to do its own random draw to decide where exactly errors are.

  Trying to model more precise different protocol options here would lead to be a very complex Phy state machine and protocol w devices

  A more general solution would be the Phy providing to the device a bit error mask
  as that would allow to generate the corrupted packet in the lowest layer of the device, and have it feed that to the radio models/stack.
  The issue with such a solution though, is that as some stacks look into as much packet as possible on the fly, that would require this bitmask to be updated on the fly.
  An option would be to allow the device to request an update to this bitmask during each abort reevaluation.
  That is, a new IMMediate procedure, something like:
    imm_req_error_mask:
      byte_array_start_offset //just to save BW, how many bytes to chop from the array (that it already got before)
    imm_resp_error_mask:
      current instant
      header_start //offset in bits in the array that marks the beginning of the header, before that it would be preamble + address
      already calculated bit array length //how much is actually filled. (At the very least we will send full bytes)
      bit array length //number of actual bytes that follow
      error bit array itself[]

* Model the length error, by asking the receiver until when will it wants to receive, and then maybe continuing after the tx end
  specially interesting for errors in the code indicator (and also length errors)
  Either in the initial Rx request, or after
  For after maybe also with an immediate command just to set that length,
  and a new structure after RXCONT in which the device can provide both this length, and a new abort structure.
  forced_packet_duration was added in the Rx struct for this.