Bumps

[geyslan]

1. Explain what the PR does

cdf51f4 chore(deps): bump go to 1.22.3
015e29b chore(builder): bump pandoc to 3.2
5bfb528 chore(builder): pin protoc versions
5170c47 chore: use NewClient instead of Dial (deprecated)
08ab832 chore: bump go.mod and go.sum
01c3539 chore(signatures): bump go.mod and go.sum
f6ccb30 chore(types): bump go.mod and go.sum
45bb393 chore(api): bump go.mod and go.sum

015e29b chore(builder): bump pandoc to 3.2

It also updates all man by generating them with the new pandoc version.

5bfb528 chore(builder): pin protoc versions

This doesn't upgrade versions to avoid changes in the protoc output
which would require updating the generated code.

5170c47 chore: use NewClient instead of Dial (deprecated)

grpc pkg introduced NewClient in v1.63.0.

SA1019  grpc.Dial is deprecated: use NewClient instead.  Will be supported throughout 1.x.

2. Explain how to test it

3. Other comments

[geyslan]

After this be merged. A sequential PR should be created bumping the main go.mod, specifically:

github.com/aquasecurity/tracee/api
github.com/aquasecurity/tracee/signatures/helpers
github.com/aquasecurity/tracee/types

So, only after that, we should update internal tests.

[geyslan]

@josedonizetti you may notice in f2d6129 that I pinned the protoc version to ensure that the generated files are not modified. But I would like to know if there is no synchronization problem with the client side when updating the versions of these files. If there's, what should be the steps to take? Or would you take care of bumping the protoc in a different PR?

[yanivagman]

Maybe a silly question, but why do we need to specify the patch version? won't 1.22 be enough?

[geyslan]

Good point. I should be using the toolchain directive here like:

go 1.22.0              // doesn't enforce any specific patch version, but doesn't limit it to 1.22.0 as minor.

toolchain go1.22.3     // do enforce this specific patch version

It's sane to make the whole environment to use the same version (patch or not).

[rscampos]

LGTM

[geyslan]

@rscampos Thanks for reviewing it. I'm holding it for a while since it's good to have @NDStrahilevitz and @josedonizetti feedback as well, since it will demand changes to internal tests and beyond.