store serialized representations of ast nodes during module caching

[JoshuaBatty]

Copying this over from a comment in #6605

The motivation for this was noticing really high RAM usage in the language server now. For example, just running the counter example we can see 800mb of heap memory is never deallocated after the first compilation pass.

On digging it seems this is due to the new module caching where we hold onto the types themselves, thus never allow Drop to be called.

#[derive(Clone, Debug)]
pub struct TypedModuleInfo {
    pub module: Arc<TyModule>,
    pub version: Option<u64>,
}

My motivation was to Serialize these types using postcard (same that is used in fuel-core) and then store the Serialize version in the module cache. We then need to Deserialize back into the original type on each keystroke which will incur some performance overhead but I haven't got any measurements yet.

[JoshuaBatty]

Just did a quick test for serializing the TyModule into bytes using postcard just before we store the results in the module cache. Looking at the initial numbers below doens't inspire much confidence that this is going to be a viable technique.

// Serialize the TyModule into bytes
let now = std::time::Instant::now();
let serialized_module = to_allocvec(&ty_module).unwrap();
println!("Serialize module took {:?} | path: {:?}", now.elapsed(), path);

Results for a single compilation pass.

Serialize module took 236.667µs | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/primitives.sw"
Serialize module took 235.292µs | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/raw_ptr.sw"
Serialize module took 358.166µs | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/raw_slice.sw"
Serialize module took 469.833µs | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/slice.sw"
Serialize module took 629.959µs | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/str.sw"
Serialize module took 3.581709ms | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/ops.sw"
Serialize module took 3.217125ms | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/primitive_conversions.sw"
Serialize module took 4.220958ms | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/never.sw"
Serialize module took 3.927834ms | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/storage.sw"
Serialize module took 39.115708ms | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/codec.sw"
Serialize module took 61.43525ms | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/prelude.sw"
Serialize module took 190.98425ms | path: "/Users/josh/Documents/rust/fuel/sway/sway-lib-core/src/lib.sw"
Serialize module took 166.33825ms | path: "/private/var/folders/gl/s6xz59l12lz11qqftc4l92180000gn/T/SWAY_LSP_TEMP_DIRUEXQC8/struct_field_access/src/main.sw"

I've also been looking at the rust serialization benchmarks and it doesn't seem like there are any other crates that are going to give up the speed we need for this to be usable in the language server. Going to start brainstorming some alternative approaches.