[VS Incentives]: remove gauge creation logic from CreateGroup, call CreateGauge instead

[p0mvn]

Context
Logic in CreateGroup essentially duplicaed gauge creation.

We should instead encapsulated any gauge creation inside CreateGauge and call that from CreateGroup

A/C

• Create group gauge in CreateGauge & update tests
• Call CreateGauge from CreateGroup
• Minimize code duplication

[AlpinYukseloglu]

I agree with avoiding duplicate code, but we should be careful about storing group gauges in state alongside regular gauges since we fetch all active gauges from state for distribution using a prefix iterator:

osmosis/x/incentives/keeper/hooks.go

Line 51 in 9691451

gauges = k.GetActiveGauges(ctx)

This means if we use CreateGauge for group gauges and by extension share keys/prefixes between group gauges and regular gauges, we should be careful to either skip group gauges during this distribution logic or in some other way exclude them from the regular gauge iterator

[p0mvn]

This is a valid concern. However, a workaround was fond and tracked:

• In CreateGauge, if the gauge being created is a ByGroup gauge, do NOT create upcoming/active/finished ref keys. Only write it to a regular gauge index.
• This will allow ByGroup bypassing being retrieved from state via GetActiveGauges because it reads from a store index that ByGroup was not written to:

  osmosis/x/incentives/keeper/gauge.go

  Line 317 in 1e83ec9

  return k.getGaugesFromIterator(ctx, k.ActiveGaugesIterator(ctx))

Additionally, we must write the ByGroup gauge intro a regular gauge index. Otherwise, we would not be able to retrieve it in a general way from pool incentive hooks when distributing from the DisrRecords :

osmosis/x/incentives/keeper/gauge.go

Line 424 in 58e1d3e

gauge, err := k.GetGaugeByID(ctx, gaugeID)

Lmk if this doesn't address your concern

[AlpinYukseloglu]

It does, great!