FT-463 : Integrate golangci-lint for Linting

[0xquark]

Description

This PR integrates golangci-lint for linting Go code, using tools like govet, gosimple, and staticcheck etc. (see config/.golangci.yaml). It also sets up a GitHub Actions workflow to run the linter on code pushes and pull requests.

Related Issue

FT-463

Checklist

• My code follows the code style of this project
• I have added tests to cover my changes (if applicable)
• I have updated documentation (if applicable)
• All the checks and tests are passing locally
• I have verified that the changes works as expected

Further Comments

[Aryamanz29]

LGTM 🚀

Just a few questions:

1. From looking into the config, it seems like it handles a lot of tasks, such as formatting, fixing imports, static checks, etc. I want to confirm: when someone pushes code, does it automatically fix those issues and create a new commit OR does it just highlight specific lines with issues through review comment?
2. I think we should also document how to run this linter locally in the README.md.
3. If we can run this locally, we should also integrate it into pre-commit to save CI time (other enhancement req). This way, the linter violations are caught during the pre-commit step before they make it to the CI pipeline ✅

[0xquark]

1. From looking into the config, it seems like it handles a lot of tasks, such as formatting, fixing imports, static checks, etc. I want to confirm: when someone pushes code, does it automatically fix those issues and create a new commit OR does it just highlight specific lines with issues through review comment?

When someone runs the linter locally using golangci-lint run, it only shows the errors. To fix them, they need to use golangci-lint run --fix. I’m not adding automatic fixes to the workflow because these decisions should be made by the person after reviewing the linter’s suggestions, as linters can sometimes produce false positives.

2. I think we should also document how to run this linter locally in the README.md.

I plan to update the README and add the Contributing guidelines, badges etc. in the next PR. I thought it would be better to handle all the documentation updates in one PR to save time and make the review process easier.

3. If we can run this locally, we should also integrate it into pre-commit to save CI time (other enhancement req). This way, the linter violations are caught during the pre-commit step before they make it to the CI pipeline ✅

Thanks for the suggestion! I forgot about it, but I’ll make sure to include it.