feat: scaffold indexed type

[lumtis]

starport type foo bar ... --indexed creates a type that is indexed by a string. Methods to set and get this type in the store are scaffolded

Queries to get the type instances are created: list-foo, show-foo <index>

The type can only be created internally. Messages to set and remove instances will be implemented in another PR.

Since there are no messages to add types, the app can be tested by adding types in InitGenesis:

func InitGenesis(ctx sdk.Context, k keeper.Keeper, genState types.GenesisState) {
	// this line is used by starport scaffolding # genesis/module/init
	for _, elem := range genState.FooList {
		k.SetFoo(ctx, *elem)
	}
	k.SetFoo(ctx, types.Foo{
		Index: "...",
		// ...
	})

}

[fadeev]

Code generation looks good! 👍

[ilgooz]

Suggested change

	string index = 2;<%= for (i, field) in Fields { %>
	string index = 1;<%= for (i, field) in Fields { %>

Not blocking.

[ilgooz]

We don't have a creator field here anymore, is it fine to not have it?

[ilgooz]

Also, what if instead of creating a new message type, can't we have an option in the existent one that enables indexing with the user given string instead? By default indexing is disabled.

This feels like will simplify our code generation logic and can be more obvious for the user.

[lumtis]

For now the type is only managed internally, you may have no creator, it's up to the developer to decide. For example, in the IBC exchange, you will have an OrderBook which is indexed by PortID*ChannelId*TokenPair you don't have creator for this one.

Also, what if instead of creating a new message type, can't we have an option in the existent one that enables indexing with the user given string instead? By default indexing is disabled.

Indexed type respond to a different logic, methods are a bit different than the other type. And you have less method generated. Also we don't know how those two kind of type will evolve in the future. We need a different template for better maintainability.

[ilgooz]

🍷