Add linters for Docker, Go, Python, and Shell

[Jeffrey-Vervoort-KNMI]

First, the refactoring of the project needs to be merged (See this branch: https://github.com/EURODEO/e-soh-datastore-poc/tree/generalize_putobservations), and then this PR can be merged. Done

This PR contains:

• Adds linters and formatters for:
  • Docker
  • Go
  • Python
  • Shell
• Adds a github actions for the linters and formatters.
• Adds a pre-commit hook with the linters and formatters.
• Updates the readme on how to install the pre-commit hook.
• Applied the pre-commit hook to all of the files.

[Jeffrey-Vervoort-KNMI]

First, I think it's great to have these linters in place! I really only have a general comment: how does the pre-commit hook work (in file .pre-commit-config.yaml) ? Is source code modified to conform to certain styles? While that's not a problem in itself, it might be challenging if your IDE/editor (vscode in my case) is configured to modify source file according to a different standard upon file save. I.e. the diffs may in certain cases contain a lot of "noise" that will make it harder to distinguish essential changes from automatically applied style changes. But I'm not sure it will work that way in practice, so I'm only guessing here :)

Rebasing was easier on a new branch. Moved Jo's comment from to here and closed the old MR.

[Jeffrey-Vervoort-KNMI]

How does the pre-commit hook work (in file .pre-commit-config.yaml) ?

I have updated the README.md in the root of the repository and added the steps to install and work with the pre-commit hook.

Is source code modified to conform to certain styles? While that's not a problem in itself, it might be challenging if your IDE/editor (vscode in my case) is configured to modify source file according to a different standard upon file save.

For me, it is the reason why I favour linters and formatters. Using them enables anyone to pick the editor they like. Because the tool is then responsible for the formatting and not the editor. Someone can then use VSCode, Intelij or even notepad.

I.e. the diffs may in certain cases contain a lot of "noise" that will make it harder to distinguish essential changes from automatically applied style changes.

The first time - which is in this MR - there is a lot of noise, thereafter the formatting should be the same for everyone. This should minimise the diffs.

[lukas-phaf]

I think what Jo is worried about is formatting "ping-pong". The editor saves with "format A", the pre-commit hooks run, reformat the code to "format B", the editor puts it back to "format A", etc.

But maybe we should just try it? As this MR adds only a single space to the Go code, and we have no issues with this in Python (although not sure if anybody uses vscode in our group) with these linters.
We can also back out if we see problems.