Refactoring executor, db, and util packages

[gauravgahlot]

Description

The changes include:

• renaming util package to pkg
• moving types from executor package to pkg
• removing executor package
• extracted template validation logic from db/workflow.goto pkg
• updated db/workflow.go to use pkg

Why is this needed?

• To reuse the template validation code.
• To write tests for template validation logic.

How Has This Been Tested?

How are existing users impacted? What migration steps/scripts do we need?

Checklist:

I have:

• updated the documentation and/or roadmap (if required)
• added unit or e2e tests
• provided instructions on how to upgrade

Coverage

➜ go test -coverprofile coverage.out 
➜ go tool cover -func coverage.out | grep template_validator.go
github.com/tinkerbell/tink/pkg/template_validator.go:19:	ParseYAML		100.0%
github.com/tinkerbell/tink/pkg/template_validator.go:30:	ValidateTemplate	100.0%
github.com/tinkerbell/tink/pkg/template_validator.go:63:	hasValidLength		100.0%
github.com/tinkerbell/tink/pkg/template_validator.go:73:	isValidImageName	100.0%

[gianarb]

Can you have a look at this to see if it triggers some thoughts? https://medium.com/@benbjohnson/standard-package-layout-7cdbc8391fc1 it is imho the best article about structuring projects in Go.

I have to think about pkg, I tend to avoid them as much as I can

[gauravgahlot]

@gianarb The intention here is to use ValidateTemplate function not only at the time of creating a workflow but also while creating a template.
I think if we can validate template at the CLI end (during create and update calls), we don't need to revalidate it at the time of creating a workflow. If so, the code can be moved to cmd/tink-cli.
What do you think?

[gianarb]

Validation has to be server-side to avoid man in the middle, manipulation that can corrupt the request when it left the CLI.

And because we have to provide a consistent experience across SDKs, cli, and so on. So validation has to stay server side.

if you think some validation can be moved in the CLI I am happy to duplicate validation. Think about this problem in this way: "there is a team writing CLI, there is a team writing the server". Both have to write code in a way that is solid.

Server-side we have to be sure that that we get is valid, no matter who sends it. In the CLI we have to offer the best experience ever.

[gauravgahlot]

Thanks @gianarb . That absolutely makes sense.

Validation has to be server-side to avoid man in the middle, manipulation that can corrupt the request when it left the CLI.

And because we have to provide a consistent experience across SDKs, cli, and so on. So validation has to stay server side.

if you think some validation can be moved in the CLI I am happy to duplicate validation. Think about this problem in this way: "there is a team writing CLI, there is a team writing the server". Both have to write code in a way that is solid.

Server-side we have to be sure that that we get is valid, no matter who sends it. In the CLI we have to offer the best experience ever.

[codecov]

Codecov Report

Merging #250 into master will increase coverage by 2.36%.
The diff coverage is 91.11%.

@@            Coverage Diff             @@
##           master     #250      +/-   ##
==========================================
+ Coverage   12.98%   15.34%   +2.36%     
==========================================
  Files           7        9       +2     
  Lines        1186     1264      +78     
==========================================
+ Hits          154      194      +40     
- Misses       1021     1059      +38     
  Partials       11       11              

Impacted Files	Coverage Δ
pkg/hardware_wrapper.go	0.00% <ø> (ø)
http-server/http_handlers.go	7.08% <20.00%> (ø)
pkg/template_validator.go	100.00% <100.00%> (ø)

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1ba20b8...df8d388. Read the comment docs.

[gianarb]

Let's move it forward as it is. I think we should try to remove pkg as well but we can do it later