Add custom error handler for content-encoding honouring

[joshuabrink]

This fixes an issue where service error response bodies were sent as uncompressed JSON while the content-encoding header was set.

This caused issues on the SDK's which used HTTP clients. They honoured the content-encoding header and read the JSON body as if it were compressed data - which lead to errors surfacing as content-encoding body mismatches or malformed compression bodies, instead of the underlying service error.

To fix this mismatch we recompresses the error bodies when content-encoding is detected on the error path.

[changeset-bot]

🦋 Changeset detected

Latest commit: 540b947

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages

Name	Type
@powersync/service-core	Patch
@powersync/service-module-core	Patch
@powersync/service-module-mongodb-storage	Patch
@powersync/service-module-mongodb	Patch
@powersync/service-module-mssql	Patch
@powersync/service-module-mysql	Patch
@powersync/service-module-postgres-storage	Patch
@powersync/service-module-postgres	Patch
@powersync/service-image	Patch
test-client	Patch
@powersync/service-schema	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[rkistner]

The fix looks good overall, but since there are some subtle edge cases to consider, it would help to have a couple of tests added for this.

The closest tests we currently have for covering fastify behavior is this:
https://github.com/powersync-ja/powersync-service/blob/2cb525226fb6a178f3b3fb7b6639111d53f5595b/packages/service-core/test/src/routes/probes.integration.test.ts

I'd recommend defining custom routes in tests to cover at least these cases:

1. Throwing error in the route, before and after setting the encoding, before sending any response.
2. Throwing an error, before and after setting the encoding, after responding with a stream, but before sending data.
3. Throwing an error, after responding with a stream and sending some data. Note that in this case we can't send a proper error response, but at the very least don't want to end up crashing the process with an uncaught error.
4. Cover some built-in fastify errors, e.g. invalid JSON in a request body. The custom error handling may need some more work to cover these cases properly, e.g. re-using the status code from the fastify error, instead of responding with a generic 500 error.