feat(accounts): init accounts module

[testinginprod]

Description

Closes: #17444

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• run make lint and make test
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[julienrbrt]

Could you follow this too:

cosmos-sdk/CONTRIBUTING.md

Lines 198 to 207 in 7b7be7e

	* Add a CHANGELOG.md / README.md under the new package folder
	* Add the package in [`labeler.yml`](./.github/labeler.yml)
	* Add the package in [`go.work.example`](./go.work.example)
	* Add weekly dependabot checks (see [dependabot.yml](./.github/dependabot.yml))
	* Add tests to github workflow [test.yml](.github/workflows/test.yml) (under submodules)
	* Configure SonarCloud
	* Add `sonar-projects.properties` (see math [sonar-projects.properties](./math/sonar-projects.properties) for example)
	* Add a GitHub Workflow entry for running the scans (see [test.yml](.github/workflows/test.yml))
	* Ask the team to add the project to SonarCloud
	* (optional) Configure a `cosmossdk.io` vanity url by submitting a PR to [cosmos/vanity](https://github.com/cosmos/vanity).

[sonarqubecloud]

[Cosmos SDK - x/accounts] Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[tac0turtle]

Lgtm

[julienrbrt]

lgtm! two nits.

[tac0turtle]

have a failing test, lets get that fixed so this can merge

[testinginprod]

have a failing test, lets get that fixed so this can merge

it's unrelated to the PR

[julienrbrt]

have a failing test, lets get that fixed so this can merge

it's unrelated to the PR

Yeah it's flaky. Weirdly it's only flaky since today. I've opened an issue for it already.

[julienrbrt]

Just realized, the types here should just be generated in the root of the module: https://docs.cosmos.network/v0.50/building-modules/structure#structure, without that /v1.
Or is this on purpose for handling multiple future versions?

[testinginprod]

Gov has the same protobuf structure: https://github.com/cosmos/cosmos-sdk/tree/main/proto/cosmos/gov/v1

[julienrbrt]

Yeah the proto structure is good. My point is about the go packages.

For gov I think it is under /types and for newer modules directly in the root.

[testinginprod]

Yeah @julienrbrt, now I understood your comment better, but I think we should always prepend package versions to protobuf generated files, because if we do a bump to v2, then would end up either moving the "old" v1 files in a v1 package (breaking change), or create a v2 package with v2 files (not breaking, but inconsistent).

I do not have a strong preference, I can also amend what I did. LMK what you think.

[julienrbrt]

Right, that makes sense. We should maybe have it under a /types folder like gov for consistency with other modules.