refactor(tools): remove gzip module reference in utils.lua

[chronolaw]

Summary

utils.lua includes many small modules, after some refactor PRs, it's time to use them directly.
This PR remove gzip functions from utils.lua, now we should use require("kong.tools.gzip").

Do you think it is reasonable?

KAG-3060

Checklist

• The Pull Request has tests
• A changelog file has been created under changelog/unreleased/kong or skip-changelog label added on PR if changelog is unnecessary. README.md
• There is a user-facing docs PR against https://github.com/Kong/docs.konghq.com - PUT DOCS PR HERE

Full changelog

• [Implement ...]

Issue reference

Fix #[issue number]

[bungle]

utils.lua includes many small modules, after some refactor PRs, it's time to use them directly.
This PR remove gzip functions from utils.lua, now we should use require("kong.tools.gzip").

Do you think it is reasonable?

@chronolaw, It is reasonable as evolutionary step. But what do you think about introducing stuff in PDK (or in PDK too), then we could most of the time just remove require, and use e.g. kong.gzip.deflate(...) / kong.gzip.inflate(...). We could have all the nice tools in PDK.

[chronolaw]

Does pdk have such requirement? If we do need it I think we could add it.

[bungle]

Does pdk have such requirement? If we do need it I think we could add it.

What do you mean does plugin developer kit have such requirement? Lua especially doesn't come with batteries included. But as seen on many of our plugins, we need batteries all the time. If those batteries were in PDK that would make it much nicer experience for Lua plugin writers to write plugins. Because then they don't need to install random rocks (how to hack them in custom builds etc), think that are they blocking etc. We have suite of tools/utils that everyone can use. Our scope is quite limited (proxying problem space), so it never has to be as big as something general purpose as JDK. But definitely it can be bigger than it currently is:

• kong.hash.sha256...
• kong.http.request...
• kong.table.clone, kong.table.deep_clone, kong.table.is_empty (we already have pdk kong.table)
• kong.gzip.deflate
• kong....

The list goes on. We can just look our plugins to see what is common and then start putting things in PDK.

That said, this is unrelated to this PR, but slightly related if we think things more broadly.

[chronolaw]

It looks very interesting, I am not very familiar with pdk development workflow, should we create some jira ticket to track it?

[dndx]

@chronolaw Ticket #?

[chronolaw]

@chronolaw Ticket #?

KAG-3060