fix: prevents fastify-compress from trying to work with something it cannot

[Aeolun]

I'm still trying to figure out how it happens (something involving tRPC responses), but for now I'll be happy if I can stop compress from trying to compress something it can't.

I assume the differing behavior between the automatic compression (hook), and manual compression (the compress function) is because you don't want to mess with payloads (e.g. serialize them) unless people explicitly call the compress function. I've kept that behavior, and the global hook simply doesn't compress if it gets something it cannot deal with, while the compress function, well, it already serialized things, so it might cause wonky behavior if you pass it a Response object.

Tests:

• Test that Response objects are not compressed on global hook
• Test that objects get serialized normally when using compress
• Test that Response objects are compressed after being serialized to {} with the compress function.

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]

Thanks for opening a PR! Can you please add a unit test?

[mcollina]

Great work! Can you document this new option?

[Aeolun]

@mcollina I considered writing something about it, but I don't think this is something that you can really document? It doesn't so much change functionality so much as prevent a messy thrown error. I can add a gotcha or something at the end of the README.md?

[mcollina]

@Aeolun yes. There is a new option passed as the config of the plugin, and that should be mentioned in the README.md