Utilize ZIO / ZQuery eager constructors and accessors wherever possible

[kyri-petrou]

NOTE: PR is going to fail because the zio-query dependency is a Snapshot version. I'll update this PR once I realise zio-query v0.7.2

This PR better utilizes ZIO and ZQuery eager methods and accessors in the following ways:

1. Use Exit.succeed wherever we don't need to capture side-effects or recurse in a method
2. In Wrappers: prefer using standard if statements to avoid lazy evaluation and extra allocations
3. In Executor: Attempt to extract an Exit from a ZQuery, and evaluate it as a pure value if it's possible

I'd like to elaborate a bit more on (3). In the GQL applications I have at $WORK, we often define our types like this:

case class Author(
  name: Query[String],
  age: Query[Int],
)

Depending on some logic that handles query composition, in some cases we already know the name and age. So we can do this:

Author(ZQuery.succeedNow("John"), ZQuery.succeedNow(55))

In such cases, Caliban can treat these query fields as pure values and reduce the field as if the type didn't contain any queries.

I run some benchmarks comparing the performance of using ZQuery.succeed vs ZQuery.succeedNow on some of the fields on MultiFieldEntity:

[info] Benchmark                                            (execution)  (size)   Mode  Cnt      Score      Error  Units
[info] NestedZQueryBenchmark.multifieldQueryBenchmark        sequential     100  thrpt    5   9664.459 ±   43.892  ops/s
[info] NestedZQueryBenchmark.multifieldQueryBenchmark        sequential   10000  thrpt    5     90.368 ±   21.104  ops/s
[info] NestedZQueryBenchmark.multifieldQueryBenchmark          parallel     100  thrpt    5   4551.865 ±   10.065  ops/s
[info] NestedZQueryBenchmark.multifieldQueryBenchmark          parallel   10000  thrpt    5     55.528 ±    1.476  ops/s
[info] NestedZQueryBenchmark.multifieldQueryBenchmark           batched     100  thrpt    5   9371.414 ±  488.100  ops/s
[info] NestedZQueryBenchmark.multifieldQueryBenchmark           batched   10000  thrpt    5     87.193 ±    8.166  ops/s
[info] NestedZQueryBenchmark.multifieldQueryEagerBenchmark   sequential     100  thrpt    5  17530.337 ±  447.433  ops/s
[info] NestedZQueryBenchmark.multifieldQueryEagerBenchmark   sequential   10000  thrpt    5    175.372 ±    9.420  ops/s
[info] NestedZQueryBenchmark.multifieldQueryEagerBenchmark     parallel     100  thrpt    5   7452.806 ±  701.639  ops/s
[info] NestedZQueryBenchmark.multifieldQueryEagerBenchmark     parallel   10000  thrpt    5     98.636 ±   12.712  ops/s
[info] NestedZQueryBenchmark.multifieldQueryEagerBenchmark      batched     100  thrpt    5  17380.816 ± 2332.441  ops/s
[info] NestedZQueryBenchmark.multifieldQueryEagerBenchmark      batched   10000  thrpt    5    179.397 ±   19.380  ops/s

Even if we were not able to fully reduce the object (since it still contains 1 field that uses ZQuery.succeed) we managed to double our throughput by extracting the values from the fields that were eagerly constructed.

[ghostdogpr]

There's no ZQuery.fromEither btw?

[kyri-petrou]

Ah yeah I'll change it