Add go-peer to Security

[number571]

Please provide package links to:

• repo link: https://github.com/number571/go-peer
• pkg.go.dev: https://pkg.go.dev/github.com/number571/go-peer
• goreportcard.com: https://goreportcard.com/report/github.com/number571/go-peer

Note: that new categories can be added only when there are 3 packages or more.

Make sure that you've checked the boxes below that apply before you submit PR.
Not every repository (project) will require every option, but most projects should. Check the Contribution Guidelines for details.

• The package has been added to the list in alphabetical order.
• The package has an appropriate description with correct grammar.
• As far as I know, the package has not been listed here before.
• The repo documentation has a pkg.go.dev link.
• The repo documentation has a coverage service link.
• The repo documentation has a goreportcard link.
• The repo has a version-numbered release and a go.mod file.
• I have read the Contribution Guidelines, Maintainers Note and Quality Standards.
• [] The repo has a continuous integration process that automatically runs tests that must pass before new pull requests are merged.
• The authors of the project do not commit directly to the repo, but rather use pull requests that run the continuous-integration process.

Thanks for your PR, you're awesome! 👍

[phanirithvij]

Awesome-go requires a code coverage of 80%, is there any particular reason your package cannot be tested?

[number571]

Indeed, 80% are not. I can name several reasons for this:

1. Some packages work together with others and cannot be tested by themselves. An example of this is cmd/hidden_lake/service/pkg/client and cmd/hidden_lake/service/internal/handler, where only the latter contains tests.
2. Some packages do not require testing at all, because certain functionality is constantly being configured in them. For example, cmd/hidden_lake/service/pkg/settings.
3. The go-peer library also contains specific software implementations in the cmd directory, which undoubtedly increases both the code base and testing time.

Not all reasons cover the entire project. There are also parts of the code that are still planned to be covered by tests. Therefore, I cannot say with certainty that everything I have described above can be considered as an excuse for reducing the percentage of testing coverage.

[number571]

I have covered most of the go-peer project with tests. Now the coverage is 93%.