feat(driver-adapters): enable Wasm on query-core

[jkomyno]

This PR closes https://github.com/prisma/team-orm/issues/280, and depends on #4444.
It also deprecates #4120.

query-core now has an optional metrics feature, which will be turned off when imported on query-engine-wasm, and turned on otherwise.

[codspeed-hq]

CodSpeed Performance Report

Merging #4445 will improve performances by 5.73%

_{Comparing feat/query-core-on-wasm32-unknown-unknown (19e0aef) with main (efbc865)}

Summary

⚡ 1 improvements
✅ 10 untouched benchmarks

Benchmarks breakdown

	Benchmark	main	feat/query-core-on-wasm32-unknown-unknown	Change
⚡	large_read	7.6 ms	7.2 ms	+5.73%

[jkomyno]

This enables pin projection, and is used to spawn tasks in a Wasm-compatible fashion.

[miguelff]

Out of curiosity. Why is it so that Wasm requires memory pinning? what is what it's pinning? is it internals to memory addressess of .TEXT or .DATA sections?

[jkomyno]

See: #4445 (comment).

[jkomyno]

task::JoinHandle<T> is a Wasm-compatible alternative to tokio::task::JoinHandle<T>.

It uses the pin_project macro to enable pin-projection.

[miguelff]

This might be related to my previous comment, actually: #4445 (comment)

Can you provide me with references as of how you realized this was needed?

[jkomyno]

Yes. So, this is not Wasm-specific. It's rather related to the implementation of a Future trait from scratch for a tokio::sync::oneshot::Receiver (i.e., a single-use received end of a synchronized tokio channel.

Consider:

use tokio::sync::oneshot::{self};

pub struct JoinHandle<T>(oneshot::Receiver<T>);

impl<T> Future for JoinHandle<T> {
    type Output = Result<T, oneshot::error::RecvError>;

    fn poll(self: std::pin::Pin<&mut Self>, cx: &mut std::task::Context<'_>) -> std::task::Poll<Self::Output> {
        todo!()
    }
}

Let's try replacing the todo!:

self.0.poll(cx)

yields

error[E0599]: no method named `poll` found for struct `tokio::sync::oneshot::Receiver` in the current scope
   --> 
    |
37  |             self.0.poll(cx)
    |                    ^^^^ method not found in `Receiver<T>`

    |
105 |     fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
    |        ---- the method is available for `Pin<&mut tokio::sync::oneshot::Receiver<T>>` here
    |
help: consider wrapping the receiver expression with the appropriate type
    |
37  |             Pin::new(&mut self.0).poll(cx)
    |             +++++++++++++       +

Let's apply the suggestion:

core::pin::Pin::new(&mut self.0).poll(cx)

which however yields

error[E0596]: cannot borrow `self` as mutable, as it is not declared as mutable
  --> 
   |
37 |             core::pin::Pin::new(&mut self.0).poll(cx)
   |                                      ^^^^ cannot borrow as mutable
   |
help: consider changing this to be mutable
   |
35 |         fn poll(mut self: std::pin::Pin<&mut Self>, cx: &mut std::task::Context<'_>) -> std::task::Poll<Self::Output> {
   |                 +++

Applying the new suggestion, we get:

```rust
use tokio::sync::oneshot::{self};

pub struct JoinHandle<T>(oneshot::Receiver<T>);

impl<T> Future for JoinHandle<T> {
    type Output = Result<T, oneshot::error::RecvError>;

    fn poll(self: std::pin::Pin<&mut Self>, cx: &mut std::task::Context<'_>) -> std::task::Poll<Self::Output> {
        std::pin::Pin::new(&mut self.0).poll(cx)
    }
}

which compiles, but leaves us exposed to the risk of pins being used "the wrong way".

pin-project is a utility commonly used when dealing with pin requirements around futures (there's a cool blog post on the matter).
There's also a similar, slimmer crate, pin-project-lite, which could be worth taking a look at.

[miguelff]

Nothing blocking

[miguelff]

Why aren't the metrics macros shimmed as the tracing macros where shimmed in query-connector?

[jkomyno]

For convenience: in sql-query-connector, the trace! macro was used twice in a single file (src/database/operations/write.rs) among the files included for the wasm32 compilation.

That shim is effectively a shortcut to avoid adding a currently un-needed metrics feature flag in sql-query-connector.

In query-core, metrics usage relies on several different functions and on he query-engine-metrics crate (which doesn't compile on wasm32-*).

Should we want conditional compilation based on the target architecture, that should be added to the source (query-engine-metrics) rather than to the consumer (query-core). But since we decided not to care too much about metrics for the vertical slice, feature-gating metrics within query-core seemed the most adapt choice.

[miguelff]

Would it make sense to extract this into its own task.rs file?

Nice, clear conditional code.

[jkomyno]

Sure, done.