feat: pass forceCloseConnections option from cli

[LucaRainone]

Enabling the proxy for the forceCloseConnections option. When enabled, this option resolves this issue. Explained in detail also inside this other issue

Please note that the original option on fastify could be both string and boolean. In fastify-cli I didn't find a smart way to manage it (it seems that's possible defining only one type in a structural way). I choose to use it as boolean/flag, leaving the only allowed string value (idle) the default option.
If there is a better standard solution, please point me in the right direction :)

Checklist

• run npm run test and npm run benchmark
• tests and/or benchmarks are included
• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[mcollina]

Why did you reformat the whole table? Can you only make the change needed?

[LucaRainone]

Ops, I believed was some linter. Instead was my IDE. Restored the untouched lines

[mcollina]

lgtm

[Eomm]

TBH I would set this config to true by default because it may cause data loss in production

• As is: an error logging message
• With default true: a request that is dropped in the middle of processing

As a user, I would be more pissed of about the 2nd default scenario.

Can't we write in the log:

process forced end. There were 2 open connections. Checkout the `forceCloseConnections` option

[LucaRainone]

TBH I would set this config to true by default because it may cause data loss in production

I don't get it.
If forceCloseConnections is true then it closes all pending connections regardless their status, causing possibly data loss. That's why it's not the default value.

If forceCloseConnections is not set in fastify-cli then it's not passed at all to fastify instance, keeping the default value of fastify option (that's idle or false depending by the server, so it tries a graceful shutdown limiting the data loss).

We can write additional infos on message, but this message could also shown in production during restart with "real" chrome connections opened: may be a false hint?