fmt: introduce golangci-lint and go vet

[gen2thomas]

see #789

Some notes:

Install the linter locally by: curl -sSfL https://raw.githubusercontent.com/golangci/golangci-lint/HEAD/install.sh | sh -s -- -b $(go env GOPATH)/bin v2.5.0 or by a way of your choice: https://golangci-lint.run/docs/welcome/install/#local-installation.

The current linter configuration is quite long, because we drop many linters caused by a single or only a few findings. This will usually decreased by the time, when those findings are fixed.

Because we have to skip some packages and this is not supported by the linters, we have to apply the linter to each allowed package (folder) separately.

This leads to following behavior for local run:

• all directories needs to be given as space separated list

This leads to following behavior for CI run when using the make file in docker container or plain setup in runner (currently implemented in this PR):

• provided GitHub Action is not used
• nice features for CI check can not be used, e.g. show findings inline

Alternatively, there are 2 other PRs using GitHub Action:

• see fmt: introduce golangci-lint and go vet use CI with action and strategy matrix #803 for using "matrix", which leads to multiple runners
• see fmt: introduce golangci-lint and go vet use CI with action and using build tag #804 for using an additional build tag "lint" to filter out unsupported packages

One other alternative way for CI would be to collect all usable packages in another folder and set this as the working directory, but this would introduce other problems:

• inline annotations will be lost, because we check another file internally
• dependencies to "own" drivers package are ambiguous

TODO:

• filter packages without dependency to "machine" imports
• add new targets to Makefile
• introduce linter configuration file
• fix all serious issues in code, normally found by "go vet" ("make check")
• tweak the configuration file
• introduce files running for CI
• make a decision for this variant or one of the 2 others (see description above)
• fix all important issues in code
• discuss about fix of small problems, e.g. unused variables etc.

[soypat]

What's the output of running all those linters? Is the output actionable/useful? Keep in mind tinygo isn't exactly Go so we may run into some/many false positives.

[gen2thomas]

@soypat as far I could see until now all output is very useful. Additionally most linters are customizable to fit our needs. You can simple try it by install the linter locally or use the docker version.