chore: use errors.New to replace fmt.Errorf with no parameters

[ChengenH]

No description provided.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[crw]

Hi @ChengenH, would you mind saying more about why these changes are necessary? Normally we would not make this type of change unless we were already working in this section of the code. If there is a security or deprecation reason for these changes please let us know! Thanks!

[ChengenH]

Hi @ChengenH, would you mind saying more about why these changes are necessary? Normally we would not make this type of change unless we were already working in this section of the code. If there is a security or deprecation reason for these changes please let us know! Thanks!

People tend to think that fmt.Errorf() need to format your error message prints something .
I think errors.Newf() is more clear.

[apparentlymart]

Hi @ChengenH! Thanks for working on this.

We tend to use fmt.Errorf in most cases because most Terraform packages already import fmt for some other reason anyway, and because fmt.Errorf provides a superset of what errors.New provides so it makes a better "default decision" for situations where the differences are immaterial.

The fact that none of these updates caused removal of import "fmt" despite the addition of import "errors" seems to support that assertion that these packages do indeed need to import fmt for other reasons anyway, and so the only cost of using fmt with a constant string is some marginal additional processing time in the error return path, and we typically don't optimize performance of the error return path.

With all of that said then, while I don't think there's anything wrong with what you did here -- using errors.New in these cases would be a reasonable decision to make in another codebase with different conventions -- this change is inconsistent with this particular codebase's typical conventions.