Testnet maintainance

[sakulstra]

Currently testnets are a mess.

All the testnets deployed by avara are outdated.
The ones not outdated and listed on https://aave.com/docs/resources/addresses were deployed by bgd, but funny enough don't have a permissionless faucet, so for most ppl they are useless as well.

Not 100% sure how to resolve this situation right now.
People are asking for an amoy testnet, but again it's unclear who will maintain this long term.

Deploying with permissionless&limitless faucet doesn't make to much sense, as of lately it only takes a few days till people break the pool. For BGD there is little incentive to maintain these things, as all our testing is done on mainnet forks instead.

---

The options I see are:

1. maintain some infra for a permissioned faucet. Takes some effort and not sure if worth it.
2. create testnets only with tokens that already have a permissioned faucet (e.g. LINK and USDC as on almost every testnet). Is probably pain for users and maintainers of interfaces because they need to go/link to different pages for different faucets.
3. create a new permissionless, but somehow limited faucet (limited minting over time, limited via amount or limiting by charging some amount in testnet base currency)

[brotherlymite]

Currently the assets listed on the testnet faucet are from the base faucet: https://faucet.circle.com/
The limitation is that we have no control over it if we wish to mint some more tokens in order to test some flows, and also number of assets on the faucets are limited.

In my opinion, we should put some effort on the aave-v3-origin repo to have a flag in the config while deploying on testnets, which will list all the assets linked to a permission-less faucet with some sort of access control which can be used to mint more tokens.

The permission-less faucet for the tokens could be capped via block.timestamp and maybe some other mechanism too so users cannot abuse it, while also having some permissioned access control mechanism which can allow multiple other contributors of the DAO to mint some extra tokens so they can tests things smoothly.

Before each pool upgrade, we can schedule an update on testnets also using the same upgrade proposal which can be useful in validating the upgrade. Maintaining testnets for all networks could be a bit of pain, so we can have some selected 2-3 networks which we can maintain in the long run. The deprecated testnet addresses should then be removed from the address book to avoid confusions.