Describe the bug
When making post/put/patch requests to endpoints that accept multipart/form-data uploads (e.g., using@fastify/multipart), fastify-racing incorrectly triggers the abort signal for every request after the payload has been parsed.

To Reproduce
Run the following fastify app

// app.js
const fastify = require('fastify')()
fastify.register(require('fastify-racing'))
fastify.register(require('@fastify/multipart'))

fastify.post('/data', async (request, reply) => {
  const signal = request.race()
  const parts = request.parts()
  const payload = {}

  console.log('Signal before', signal.aborted) // false
  for await (const part of parts) {
    if (part.file) {
      payload[part.fieldname] = await part.toBuffer() // to consume the stream
    }
  }
  console.log('Signal after', signal.aborted) // true
  await fetch('https://example.com', { signal }) // as a result, calls like this will always be aborted

  return "Ok"
})

const start = async () => {
  await fastify.listen({ port: 3000 })
  console.log('Server running on http://localhost:3000')
}
start()

Then call the endpoint, e.g. using curl (assumes app.js is in the same directory):

curl -X POST http://localhost:3000/data -F "[email protected]"

results in

{"statusCode":500,"code":"20","error":"Internal Server Error","message":"This operation was aborted"}

Expected behavior
Expect the signal to not be aborted yet.

Desktop (please complete the following information):

• Node version: v20.18.0
• Package versions: [email protected], [email protected], @fastify/[email protected]
• OS: macOS 14.5 (23F79)

Additional context
It is probably related to fastify/help#866.
The request.raw.closed event is fired as soon as the request payload is consumed, so unfortunately, it is not a reliable way to detect if the request was aborted.
There is probably no easy fix, if there is one at all.