Introduce zstd & brotli compression + output buffering

[BelleNottelling]

This PR will allow FOSSBilling to provide zstd, brotli, gzip, and deflate output compression on any webserver so long as the needed extensions are installed & opens up the ability for us to have programmatic control of it within the application.

The most interesting of these would be zstd which doesn't have official support by either NGINX or Apache. It's faster than any of the other options and overall matches brotli for compression, making it by far the superior choice for output compression.

This does have the chance to break stuff, however due to introducing output buffering. Essentially any instance where code uses exit will first need to use ob_end_flush to ensure the output is sent to the client.

Also output compression in FOSSBilling can be disabled so it can instead be handled by the webserver if desired, although I personally am in favor of being able to control as many aspects of FOSSBilling's behavior within the app itself as it helps minimize potential changes to config files once we have more webservers we provide support for (further down the line, I presume after most of the routing has been rewritten).

I plan on leaving this as a draft till others comment on what they think, as I am not entirely sure if there is perhaps a better way to make these changes.

For example: since this would already be messing with how the app outputs data, maybe we should go one step further and port a lot of the core functionality to a micro-framework such as Flight & eliminate most of the custom routing / response handling in FOSSBilling which would benefit the app in the long-run.

[admdly]

FWIW, while I see this has now been closed and I'd hoped to provide a more comprehensive response, I don't think this is within our purview to worry about given limited resources.

[BelleNottelling]

FWIW, while I see this has now been closed and I'd hoped to provide a more comprehensive response, I don't think this is within our purview to worry about given limited resources.

I actually only closed this because I think such changes are better suited to if / when we rebuild the routing & app as this fundamentally needs to change how output is sent to the client (utilizing an output buffer).

CompressionBuffer is my own thing that I maintain and use in other projects so from that front it's not any additional work. The only usage of our resources is actually implementing it which is just about zero work once an output buffer is in use.

Additionally CompressionBuffer itself handles interpreting the client headers, selecting the best encoding, and outputting the proper headers needed so we wouldn't even need to worry about that from a FOSSBilling side of things.

In terms of our time investment, It's a lot like AntLoader package I built and then incorporated into FOSSBilling since composer's autoloader didn't fit our needs.

(It's also worth noting that I really do want us to eventually port the app to a micro framework & replace the existing routing, I think in the long-term that'd be good for the app & at that time I will likely be interested in revisiting this idea, even if not fully committed to it)