Add trader Gzip link support

[vaisest]

Fixes #2508

Description of the problem being solved:

In 0.5.5 the trader API was changed slightly. Note that the trader still works smoothly for now, at least. The only real problem is that the "Price Item" button doesn't work since the GET search endpoint was removed.

The 0.5.5 changes are:

• Short codes were replaced by B64 GZipped JSON. This is similar to the ?q= parameter, with the exception that it only has the query field. I.e. you can't set the sort order with it. The query parameter still seems to exist, but I'm not convinced it will stay there forever, since GGG said some functionality will be removed after ~1 month.
• A GET search endpoint was removed. This is fine since now there's no need to fetch the short code IDs since we can just decode them.

This depends on PathOfBuildingCommunity/PathOfBuilding-SimpleGraphic#117 for Gzip support.

Steps taken to verify a working solution:

• Buy similar works
• Unauthorized trader link works
• User-provided url authorized search works
• Authorized search flow works
• Tests updated

[vaisest]

Note that I changed this so that only the PoB zlib is used. Otherwise the file is just https://github.com/hamishforbes/lua-ffi-zlib/blob/master/lib/ffi-zlib.lua

[meehl]

The copyright/permission notice for ffi-zlib.lua is missing.

[meehl]

Seems kind of strange to do the whole ffi dance when SG already supports compression. Currently it does zlib-wrapped deflate by default but it could easily accepts a parameter to select between zlib- and gzip-wrapped deflate.

[vaisest]

Seems kind of strange to do the whole ffi dance when SG already supports compression. Currently it does zlib-wrapped deflate by default but it could easily accepts a parameter to select between zlib- and gzip-wrapped deflate.

It was mostly because there are some annoying issues with the headless wrapper lacking compression support which timeless jewels need to work properly.

But I could definitely remove this and instead add it to SG if that is preferred

[meehl]

Well, i don't have any say in what is preferred - the maintainers have to decide on that. It just feels wrong to me on a conceptual level.
In my mind, SG represents the interface to the underlying system and i wouldn't want the Lua side to suddenly start calling into system libraries. It's also inconsistent that for zlib compression we call into SG but for gzip we suddenly do some ffi magic. 🤷

[vaisest]

Well, i don't have any say in what is preferred - the maintainers have to decide on that. It just feels wrong to me on a conceptual level. In my mind, SG represents the interface to the underlying system and i wouldn't want the Lua side to suddenly start calling into system libraries. It's also inconsistent that for zlib compression we call into SG but for gzip we suddenly do some ffi magic. 🤷

Fair enough. I added it to SG and converted this to use that. It definitely makes more sense

Though to be clear my plan was to just add Zlib directly to the Lua side. I would still like to add bindings for Zlib so that the headless wrapper works properly with timeless jewel data. It's not all that magical, and uses the SG-provided DLL, not a system library.