[TT-561] move chainlink-env as a package (commit-splitted)

[Tofel]

Changes:

• chainlink-env code needs migrated and converted to a package ✅
• all import paths updated ✅
• fixed all issues reported by linterns ✅
  ** imports and examples excluded from analysia
• the ci and tests migrated and passing ✅
• Dockerfiles adjusted and working ✅
• Infra permissions will need to be added to chainlink-testing-framework to push the expected docker images into ECR ❓ @tateexon
• chainlink tests work using migrated code: PR

[codecov-commenter]

Codecov Report

Attention: 6 lines in your changes are missing coverage. Please review.

Comparison is base (ccb8ba3) 21.43% compared to head (260ff81) 21.75%.
Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #747      +/-   ##
==========================================
+ Coverage   21.43%   21.75%   +0.32%     
==========================================
  Files          31       32       +1     
  Lines        4167     4183      +16     
==========================================
+ Hits          893      910      +17     
+ Misses       3182     3181       -1     
  Partials       92       92              

Files	Coverage Δ
client/mockserver.go	39.69% <ø> (ø)
client/postgres.go	0.00% <ø> (ø)
logging/log.go	56.52% <ø> (+13.04%)	⬆️
blockchain/ethereum.go	0.00% <0.00%> (ø)
k8s/config/overrides.go	68.75% <68.75%> (ø)

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[tateexon]

It might make sense to put the chainlink-env package into a folder called k8s instead of env. My reasoning for this is that we have a folder called docker which hosts the docker specific stuff so it makes sense if you want to look for k8s specific stuff you would open the k8s folder instead of env.

[tateexon]

The part I am unsure about is whether we should add this as a package or just migrate the code in so we only have the 1 go project. They both have their pros and cons. 1 go project is easier to work within but the separation of the two may make it easier for projects that only want to import 1 part or the other. I think most projects will use both anyways so it may make sense to have it just be 1 project instead of two. @AnieeG @skudasov @kalverra @gheorghestrimtu @lukaszcl Thoughts?

[Tofel]

@tateexon also thought about that and checked how many projects use only chainlink-env and yes, there were a couple (e.g. Atlas from @gheorghestrimtu).

In the end I decided against having env as a separate module, because:

• it would have to share the same tag as CTF unless we went with git subtree, which would increase complexity (e.g. we couldn't commit changes to CTF and k8s in the same commit)
• CTF isn't that heavy of a module/repo to worry about having to download it and it's dependency, when you only need k8s code
  and a couple of others that I cannot recall now (had them written down, but didn't save/share).

Anyway let me know your thoughts guys.

Also, I was thinking that if we stick to packages qa-charts could be put in k8s/charts?

[lukaszcl]

@tateexon @Tofel +1 for a single go project. I think it makes more sense here. Also, I think we should have one CTF tag.

Also, I was thinking that if we stick to packages qa-charts could be put in k8s/charts?
@Tofel yes, that looks good

Removing my review for now in case we switch to 1 go project

[AnieeG]

The package name in comment

[sebawo]

@tateexon @Tofel +1 for a single go project. I think it makes more sense here. Also, I think we should have one CTF tag.

I agree we should have one release cycle for CTF+chainlink-env+qa-charts. This is one of the motivations to merge repos and have separate releases for modules.

[cl-sonarqube-production]

SonarQube Quality Gate

0 Bugs
0 Vulnerabilities
0 Security Hotspots ( 100.0% reviewed)
908 Code Smells

No Coverage information
2.6% Duplication