Support Node.js v19

[RafaelGSS]

Apparently, the semver-major that affects Fastify is only nodejs/node#43522.

However, it's leading to some weird inconsistencies. The remaining failing tests are:

• test/close-pipelining.test.js
• test/close.test.js

I did a quick investigation and looks like the original behaviour of graceful shutdown has changed. For instance, the following snippet is not returning 503 for the second request as expected:

  const fastify = Fastify({
    return503OnClosing: true,
    forceCloseConnections: false
  })

  fastify.get('/', (req, reply) => {
    // once it's called, the next request will throw a `UND_ERR_SOCKET` even trying to reutilize the connection
    fastify.close() 
    reply.send({ hello: 'world' })
  })

  fastify.listen({ port: 0 }, async err => {
    t.error(err)

    const instance = new Client('http://localhost:' + fastify.server.address().port, {
      pipelining: 1
    })

    const codes = [200, 503]
    for (const code of codes) {
      // the first request works fine
      // the second request throws UND_ERR_SOCKET
      instance.request(
        { path: '/', method: 'GET' }
      ).then(data => {
        t.equal(data.statusCode, code)
      }).catch((e) => {
        t.fail(e)
      })
    }
    instance.close(() => {
      t.end('Done')
    })
  })

cc: @ShogunPanda

[mcollina]

I have a feeling this might be a bug in Undici: nodejs/undici#1670.

Undici is closing the socket early even if there is more data to process.

[github-actions]

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.