Programmatically display external gauges

[JeremyParish69]

Currently, the Osmosis Frontend requires a manual, explicitly defined external gauge id (and ibc/denom hash) to be able to display on the pool's page. (see the 'Bonus bonding reward' boxes below)

It would be of much benefit to automatically pull bonding rewards for each pool by querying on-chain data for new external gauges. -The Osmosis Frontend Repo would see fewer PRs to manage. -Teams wouldn't need figure out how to manually define the gauges into the repo. -Teams would need to wait for Osmosis Frontend repo maintainers to verify, validate, and merge PRs before external gauges can appear (potentially having rewarded epochs go before users can see that they'd be getting rewards) -Teams would have less reason to postpones adding external gauges. -etc.

To avoid external gauge spam, some restrictions should be placed before displaying any external incentive gauge./ We don't want to see any flooding of a pool's page with these boxes, or 'tricking' users into thinking they're receiving lots of incentives when really it's just small amounts of a lot of different tokens.

Initial Suggestions of restrictions:

1. Make sure it's a significant amount: -Minimum daily emissions (by $ dollar value)

2. Make sure the token is 'valid' -Token type limited to non-GAMM tokens

Open to hearing other ideas.

[jonator]

Logic would likely live here:

https://github.com/osmosis-labs/osmosis-frontend/blob/8f7c886a722061d0e853d306bc5c3f2bf5c01fc3/packages/stores/src/queries/pools/pool-details.ts#L287-L312

This function would become a getter and we would apply the above outlined conditions as filters on the gauges returned. Instead of using allowedGauges, you would call the getter above; allExternalGauges to begin filtering.

[jonator]

May be important to do this now that @JeremyParish69 is creating a script to automatically get a config for all active gauges (see PR #1178), which no longer takes into account whether a gauge is spam or not. The script approach is needed since the external gauges query is extremely expensive to load (3k+ gauges, most expired) on every frontend.

[jonator]

Now that we're using a gauge query on the next.js server, we could look into doing the vetting there.

[jonator]

@JeremyParish69 have we even seen or heard of any complaints of scammy gauges that made it past our filter? If not, I may close this for now.