[Perf] Skip costly validation for stored data

[vicsn]

Motivation

Currently, every time an object is deserialized, input validation is performed. Ideally, we only perform input validation on data received from the network, not from disk.

This PR takes an initial stab at skipping the most expensive input validation with the smallest possible code diff. Deserialization of a Subdag and its contents is now about 10x faster, see the new dag.rs benchmark (half of which is due to skipping is_in_correct_subgroup_assuming_on_curve).

Whenever we (de)serialize from disk, we use bincode (which in its current use just prepends some bytes to to_bytes_le). Bincode calls into Deserialize::deserialize, which now calls into FromBytesUncheckedDeserializer, which now calls into from_bytes_le_unchecked.

Test Plan

• CI passes
• Run a local network, with traffic and restarts

Open TODOs

• Ensure that Deserialize::deserialize is only used when getting data from disk, consider enforcing types are Verified in the DataMap interface.
• Profile which objects we're actually reading from disk in practice, given that we have so many caches.
• Look into correctness of from_x_coordinate_unchecked
• New functions and types are all defined consistently, in the same order, with clear comments
• Update Cargo.lock
• Review if the recently added transmissions cache is still warranted

[ljedrz]

nit: a more std-like name for such a function would be from_unchecked_parts or from_raw_parts; I'd personally prefer it, as it clearly indicates that the underlying objects are of interest, as opposed to an alternative representation of the same object

the same suggestion applies to the other instances of this name

[ljedrz]

I am very much in favor of this direction; once something is in our own local storage, it should be considered trustworthy/valid.

Check that Deserialize::deserialize is only used when getting data from disk, consider enforcing this somehow.

If we feel that we need to be more careful about the handling of objects that may not be verified, we could introduce a wrapper struct to indicate with certainty that they either are or are not (determined by how they were deserialized), and use it as a parameter/generic in the relevant functions/methods. This, however, could have a large impact on the diff (but not performance, as it would be zero-cost).