feat: query compiler proof of concept

[aqrln]

Separate query planning and execution and lower the query graph into a format executable by the client.

Translates, for example,

prisma.user.findUnique({
    where: {
        email: Prisma.Param("userEmail")
    },
    select: {
        val: true,
        posts: true,
        profile: true,
    }
})

to

let @parent = query «SELECT "public"."User"."id", "public"."User"."val" FROM
                     "public"."User" WHERE "public"."User"."email" = $1 OFFSET
                     $2»
              params [var(userEmail as String), const(BigInt(0))]
in let @parent$id = mapField id (get @parent)
   in join (get @parent)
      with (query «SELECT "public"."Post"."id", "public"."Post"."createdAt",
                   "public"."Post"."updatedAt", "public"."Post"."published",
                   "public"."Post"."title", "public"."Post"."content",
                   "public"."Post"."authorId" FROM "public"."Post" WHERE
                   "public"."Post"."authorId" IN /*
                   prisma-comma-repeatable-start */$1/*
                   prisma-comma-repeatable-end */ OFFSET $2»
            params [var(@parent$id as String),
                    const(BigInt(0))]) on left.(id) = right.(authorId) as posts,
           (unique (query «SELECT "public"."Profile"."userId" FROM
                           "public"."Profile" WHERE "public"."Profile"."userId"
                           IN /* prisma-comma-repeatable-start */$1/*
                           prisma-comma-repeatable-end */ LIMIT $2 OFFSET $3»
                    params [var(@parent$id as String), const(BigInt(1)),
                            const(BigInt(0))])) on left.(id) = right.(userId) as profile

which is then executed by the QueryInterpeter on the client.

Processing query graphs with more than one node is work in progress. Functions in the edges (data dependencies) can be executed at compile time thanks to the new Placeholder abstraction (we can algebraically substitute future values not yet fetched from the database into the inputs of downstream graph nodes and continue building the query with them before those values actually exist). Flow and computation nodes need to be redesigned though.

Client: prisma/prisma#25511

[github-actions]

WASM Query Engine file Size

Engine	This PR	Base branch	Diff
Postgres	2.117MiB	2.106MiB	11.146KiB
Postgres (gzip)	848.034KiB	844.559KiB	3.475KiB
Mysql	2.079MiB	2.068MiB	11.919KiB
Mysql (gzip)	834.060KiB	830.604KiB	3.457KiB
Sqlite	1.987MiB	1.976MiB	11.335KiB
Sqlite (gzip)	797.124KiB	793.008KiB	4.116KiB

[codspeed-hq]

CodSpeed Performance Report

Merging #5024 will not alter performance

_{Comparing compiler (7d1763d) with main (bc5b021)}

Summary

✅ 11 untouched benchmarks

[aqrln]

Unrelated changes, can be dropped or extracted to a different PR

[jacek-prisma]

I wonder if it might be worth introducing a separate type at this point, to guarantee we don't try to put one of these in an actual database query,
We could maybe have ValueType with a type parameter that turns Var into Never when we output a database query, or just a separate enum