[Testing] chore: add testkeyring pkg

[bryanchriswhite]

Summary

Human Summary

Adds a set of pre-generated accounts (i.e. addresses and mnemonics) and APIs which can be used to consume them. This is useful for populating the keyring and/or module genesis states.

It also includes the package used to generate the accounts and adds a make target for its usage (go_testgen_accounts).

AI Summary

Summary generated by Reviewpad on 04 Dec 23 11:51 UTC

This pull request includes the following changes:

1. In the file miner_test.go, the comment regarding regenerating fixtures has been updated. The previous comment mentioned using "make go_fixturegen", while the updated comment suggests using "make go_testgen_fixtures" to regenerate fixtures.

2. In the file template.go in the pkg/relayer/miner/gen/ directory, there are changes to comments regarding regenerating fixtures. The comment now recommends using the command make go_testgen_fixtures to regenerate all fixtures and go generate ./pkg/relayer/miner/miner_test.go to regenerate only this test's fixtures.

3. In the file accounts.go in the testutil/testkeyring package, a new file has been introduced. It defines several structs and functions related to pre-generated accounts used in tests. The file provides a way to iterate over pre-generated accounts, retrieve accounts at specific indexes, and encode/decode account information using base64 and JSON.

4. The diff in the file relay_fixtures_test.go in the package pkg/relayer/miner includes changes to generated test fixtures. It is advised not to manually edit this file as any changes will be overwritten upon regeneration. If you need to regenerate all fixtures, use the command make go_testgen_fixture. If you only want to regenerate fixtures for this specific test, run go generate ./pkg/relayer/miner/miner_test.go.

5. There are changes made to the file testkeyring/keyring.go. It includes the addition of a new file with changes related to the creation and management of pre-generated accounts in a keyring for testing purposes.

6. A new file testutil/testkeyring/gen_accounts/gen.go has been added. It is a Go program that generates pre-generated accounts. It reads command-line flags, creates a new in-memory keyring, generates accounts, and stores their information in a file.

Please review and verify these changes.

Issue

• [Protocol] MVP implementation off the on-chain CreateClaim message handling #140

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
• Verify Localnet manually: See the instructions [here](TODO: add link to instructions)

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]

1. I really like this design but wanted to challenge (again) the need for an iterator at all
2. I came by [1], and WHAT A THREAD

[1] golang/go#54245

[bryanchriswhite]

🤩 Nice find - thanks for sharing!

I definitely want to iterate on he current design but I think an iterator pattern will support much simpler and easier to reason about tests/helpers. My goal was to still support access by index, as in some specific cases that makes more sense; however, I imagine that the majority of the time it will just be more convenient to call a #Next() method to get a unique account instead of having to track an index and/or a container yourself. I also plan to add some examples to illustrate what I'm imagining.

[Olshansk]

I definitely want to iterate on he current design but I think an iterator pattern will support much simpler and easier to reason about tests/helpers. My goal was to still support access by index, as in some specific cases that makes more sense; however, I imagine that the majority of the time it will just be more convenient to call a #Next() method to get a unique account instead of having to track an index and/or a container yourself. I also plan to add some examples to illustrate what I'm imagining.

I understand where this is coming from but still feel like we're overengineering something that can be a basic list. I'm not 100% convinced we'll need this at the moment, so will push back unless unless using #Next() makes the first application of this pattern easier to reason about.

[bryanchriswhite]

I believe that it already does in #236. The fact that the keyring can be populated in one line completely separately from where the keys purposes are designated and used in on-chain state is indicative of the kind of coordination avoidance this enables. I feel like we would end up re-implementing this behavior in several places if we don't centralize it here, it seems inevitable to me that we would be iterating over such a list.

[bryanchriswhite]

The requirements here will continue to get more complex (at least) until we finish with proof validation. Wdyt about waiting until then before rendering final judgement?

[Olshansk]

Wdyt about waiting until then before rendering final judgement?

I personally think that if we merge it in, we'll never go back to remove it.

However, you seem pretty adamant that this is he right approach so I trust you on that 🤝

[Olshansk]

Nice, ty for doing this!

[Olshansk]

Approved!!