test/fix(client): await blocking IO

[danstarns]

Awaits blocking IO in client/integration tests:

Related: #13092

[aqrln]

Is there a reason you merged this into a single test?

[danstarns]

I have changed this back to what it was before. I initially changed this test because when running the test it I get:

(node:39400) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. Use emitter.setMaxListeners() to increase limit
(Use `node --trace-warnings ...` to show where the warning was created)
(node:39400) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGTERM listeners added to [process]. Use emitter.setMaxListeners() to increase limit

Then secondly because its running all theses tests sequentially:

client engine
    √ expects(binary) | PRISMA_CLIENT_ENGINE_TYPE=binary | engineType=binary (2585 ms)
    √ expects(library) | PRISMA_CLIENT_ENGINE_TYPE=library | engineType=binary (1641 ms)
    √ expects(binary) | PRISMA_CLIENT_ENGINE_TYPE=undefined | engineType=binary (1953 ms)
    √ expects(binary) | PRISMA_CLIENT_ENGINE_TYPE=binary | engineType=library (1954 ms)
    √ expects(library) | PRISMA_CLIENT_ENGINE_TYPE=library | engineType=library (1547 ms)
    √ expects(library) | PRISMA_CLIENT_ENGINE_TYPE=undefined | engineType=library (1538 ms)
    √ expects(binary) | PRISMA_CLIENT_ENGINE_TYPE=binary | engineType=undefined (1955 ms)
    √ expects(library) | PRISMA_CLIENT_ENGINE_TYPE=library | engineType=undefined (1596 ms)
    √ expects(library) | PRISMA_CLIENT_ENGINE_TYPE=undefined | engineType=undefined (1544 ms)

each making more than three calls to disk for each test.

[janpio]

Potentially stupid question: What is the difference of these to how it was run before?

[aqrln]

Probably doesn't matter in this case. Technically it'll even be kinda slower because of the overhead of creating a new task on the thread pool and then just waiting for it without doing anything else on the main thread (since there shouldn't be anything else running concurrently with the beforeAll hook in one Jest worker), but the difference should be negligible.

[aqrln]

@janpio

Potentially stupid question: What is the difference of these to how it was run before?

I don't think there should be any observable difference in these cases, since all of these changes are in tests, and Jest only parallelises tests across multiple workers (separate Node.js processes each with their own event loop), it doesn't run tests concurrently in a single worker^[1]. So what I wrote in a previous comment really applies to all or most of these changes to a certain extent, but in functions that are already async it still makes total sense at least as a stylistic change.

---

^[1]At least it tries not to, but sometimes, e.g., some leftover async tasks may be executing after a test times out.

[aqrln]

it doesn't run tests concurrently in a single worker

Or, rather, it shouldn't. If it somehow does on @danstarns's machine, it may be the reason behind #13092