[Linting] Enforce 120 max lines, and import order with custom linting

[h5law]

Summary

Human Summary

• Enforce max lines as 120 in all files except errors.go files (using lll)
• Enforce import order (std, external, internal) (using gci)
  • Excludes generated files
• Enforce gofumpt formatting
• Disable enforcement for certain files
• Create workflow for this for CI
• Fixes all linter errors for the entire repo so we can enable them for new PRs only

make go_gci will order all eligible .go files imports to be std,external,internal
- here non eligible files are ones with ignite scaffold comments you need to do them yourself as gci will remove the comment
make go_gofumpt will format (scricter than gofmt) all eligible '.go' files
- non-eligible files mostly include generated files like mocks and protobuf generated code
make go_lint will show any linter errors

These three makefile targets rely on you first running make install_ci_deps which will install golangci-lint, gci and gofumpt if you don't already have them. These are configured in the .golangci.yml file and the workflow file for running tests.

From now on PRs will (🤞🏼) show checks not comments where you have linter errors.

Issue

• Fixes N/A

Type of change

Select one or more:

• New feature, functionality or library
• Bug fix
• Code health or cleanup
• Documentation
• Other (specify)

Testing

• Run all unit tests: make go_develop_and_test
• Run E2E tests locally: make test_e2e
• Run E2E tests on DevNet: Add the devnet-test-e2e label to the PR. This is VERY expensive, only do it after all the reviews are complete.

Sanity Checklist

• I have tested my changes using the available tooling
• I have performed a self-review of my own code
• I have commented my code, updated documentation and left TODOs throughout the codebase

[Olshansk]

Halfway through

[red-0ne]

Thanks for going through all the codebase 🙏

[red-0ne]

This seems to be required

[Olshansk]

@h5law Should we move this one to a draft state if it's not under active review/development?

[h5law]

This is probably a good community task as picking up from what I started shouldn't be too hard with the tooling added. Moved into draft and put into iteration 14 «Developer Experience»

[Olshansk]

This is probably a good community task as picking up from what I started shouldn't be too hard with the tooling added.
Moved into draft and put into iteration 14 «Developer Experience»

@h5law I'd rather have someone on the team do this. When you introduce a (trivial) change that touches a large surface area of the codebase, it's better to be done by the core team.

Pick it up in iteration 14 and we should be 🏅

[Olshansk]

Outdated.