feat: improve performance (esp. n+1) by batching requests

Prisma will perform query optimizations at the engine level if multiple
similar queries are sent inside the same tick, by automatically batching
them together into a single larger query. This feature dramatically
improves performance for graphQL servers, avoiding the "n+1" problem.
By default, Prisma will batch requests by the transaction ID if it is present,
but this behaviour prevents automatic batching from working when using Yates, since all queries are executed inside an interactive transaction.
To get around this we by monkey patching the batching function to use the Yates ID as the batch ID.
To get the batching to work we also need to ensure that all the requests we might want to batch together are generated inside the same tick.
This means that all the requests per-tick that have the same role and context values will be batched together,
allowing the in-built prisma batch optimizations to work for us.
This is why we use process.nextTick and the tickActive flag to ensure we only tick once at a time.
See:
- https://github.com/prisma/prisma/blob/5.21.1/packages/client/src/runtime/RequestHandler.ts#L122
- https://www.prisma.io/docs/orm/prisma-client/queries/query-optimization-performance

biome.json

@@ -1,15 +1,18 @@
 {
 	"$schema": "https://biomejs.dev/schemas/1.5.3/schema.json",
 	"files": {
-		"ignore": ["dist", "coverage"]
+		"ignore": ["dist", "coverage", "package.json"]
 	},
 	"organizeImports": {
 		"enabled": true
 	},
 	"linter": {
 		"enabled": true,
 		"rules": {
-			"recommended": true
+			"recommended": true,
+			"suspicious": {
+				"noExplicitAny": "off"
+			}
 		}
 	}
 }