Bit-level mutations through lazy bitstring replacements

[LCBH]

One approach to integrate bit-level mutations (like HAVOC) to tlspuffin and DY fuzzing in general is as follows:

1. Have a mutation make_bitstring that:
   a. randomly choose a sub-term t in a recipe in the current trace (similar to what is done in this clone,
   b. evaluate it to a bitstring b,
   c. associate a mutable version of b, amenable to bit-level mutations, to t in fields payload and initial_payload of t.
   The idea is that, from now on, future evaluation of t will use payload instead of using the evaluation of t and bit-level mutations can mutate in-place the field payload.
2. Have bit-level mutations like HAVOC operating on all payloads of all sub-terms of all recipes in the trace.
3. When evaluating the trace and one of its recipe t:
   a. evaluate it to b_t as currently done.
   b. for each sub-term t' of t having a payload b (hence make_message has been used on t'), do the following:
   • replace t.initial_payload that must be found in b_t by t.payload (even if the two do not have the same size)
   • [Optional] if multiple t.initial_payload can be found at different locations, find the right location corresponding to t'. (One option is to evaluate the first child of t that has t' as descendant, evaluate this child as a bitstring, and find b_t in it. If there is only one matching location, then we win, otherwise, we recursively do the same on this child (instead of t).
4. Send the modified b_t to the suitable agent.

Pros:

• compared to [Constant bitstrings in atoms (for bit-level fuzzing) -- Attempt with Codec::read_bytes #278], this approach allows to accept any kind of bit-level mutations. Approaches based on re-interpreting the mutated bit-strings in the Mapper internal structure (here rustls) rejects a lot of mutations that make this re-interpretation/parsing fail. Problem 1: We are not really interested in fuzzing the Mapper: a mutation that may be gracefully rejected by the Mapper might crash the PUT's "Mapper"/parsing routines. Problem 2: even if we used the PUT as Mapper, the context of evaluation in our fuzzer will not be the same as the one of the agent we fuzz, hence some bugs may be missed because of we reject a mutation on the fuzzer side (parsing fails) but this would still crash the PUT.
  --> This approach does not suffer from those problems, any bit-level mutation will go through.
• we are able to fuzz any sub-terms with this approach. On the contrary, approaches based on fuzzing rustls payloads (like this clone) are only able to fuzz certain parts of messages (such as certificates). Problem 3: structures of messages (header, length, etc.) cannot be fuzzed this way.

Cons:

• quite cumbersome and hacky
• tracking down which precise location of the bitstring b to replace is non-trivial (but possible)
• we need to re-architecture the interface tlspuffin-puffin since no bitstring-access to the PUT agents are exposed (for sending bitstring), only message-level-access to the PUT is exposed
• maybe too inefficient once we have a lot of sub-terms with payloads (?)

Question: some HAVOC sub-mutations are more expressive if we give them the concatenation of all payloads of all sub-terms (e.g., the ones that swap around some parts of the bitstrings). We may want do to that but reconstructing the new mutated payloads after having applied the mutation is non-trivial.