Test net [FEATURE] title-of-feature

[Rexyz123]

Problem definition
A clear and concise description of what the problem is. Ex. I'm always frustrated when [...]
Updated code that is released without appropriate L2 testing introduces risks to the TerraClassic ecosystem by introducing instability and in turn drives away customers and investment.
Issue expanded - It has been stated by LBA in a recent update that L2 issues are out of scope of the L1 team. This is not acceptable. Without utility there is no need for L1, the output of L1 is the input of L2, if they do not anticipate the needs and impacts of actions on each other the chain will not maximise it's value.

Feature specification
A clear and concise description of what you want to happen.
TerraCVita is offering to build and is currently exploring the feasibility of creating a Testnet that dApps and Validators can use to test new code before it is released. This test net will be an extension of the current endpoint infrastructure that TerraCVita is operating.
Infrastructure would consist of a full mirror image of the operational infrastructure but on a smaller scale. i.e. LCD, RPC gRPC, FCD and Mantlemint.
From an Apps perspective before release all issues need to be identified and L2 apps need to be informed in advance in a timely manner of any updating or changes they need to make to reduce the impacts on the service that they deliver to the customers. Constant iteration of code bringing new problems and instability and expecting Apps to simply work around these new problems simply drives customers away.

Additional context
Add any other context or screenshots about the feature request here.
By collaborating on this fundamental necessity for the chain it will reduce down time and also negative reporting regarding code upgrades. This gives an opportunity to promote the chain as being stable and customer and developer focused helping us to drive the building and use of the chain by removing barriers to its use.

Acceptance criteria
Specify the desired outcomes of resolving this issue.
Necessary
a) L1 team decides whether they wish to use the TCV testnet if we create it.
Necessary
b) L1 team assigns a person to coordinate with TCV regards this - Frag has volunteered, which as a member of both L1 and TCV seems sensible.
Necessary
c) L1 team supports the efforts of TCV to encourage dapp operators and validators to join the test net and make it affective (TCV has a validator discord) group,
Desirable
d) L1 team supports the Terra Luna Classic Validators Discord as a (the) primary discord for communicating testnet information.
e) L1 team will support reasonable requests for community funding of the infrastructure provided by TCV including a testnet.

• Criteria 1
• Criteria 2
• Criteria 3

[ZaradarBH]

@Rexyz123 the problem is not really setting up an actual testnet. Its getting the validators to join it :)

[Rexyz123]

I agree. TCV has helped multiple validators to be created and is helping them to market themselves. Maybe this gives those validators an opportunity to give something extra back. TCV do not currently charge for support services, as our reward is the expansion of the ecosystem and its continued stability.

[OhhBilboBaggins]

I'm in support of this general idea and it's something I've discussed / proposed a couple times before as well, so thanks for getting the discussion started on this.

How robust should this proposed testnet be? How much validator participation are we looking for on the testnet? If we're going to have validators join a testnet, the work for managing that testnet that shouldn't need to all be on TCV, we could have multiple validators agree to run the testnet on their machines and take some of the operational load off of TCV.

Having a testnet would also be better for educating new validators too because they'd be going through software upgrades and other validator responsibilities on testnet before doing those same actions on mainnet, so they'd grow their knowledge at a faster rate in lower stakes environments (in theory).

[ZaradarBH]

The optimal scenario would be the L1 team or TCV running a seed node for the test net and then having all validators in the mainnet active set join with a minimalistic host that uses an identical configuration to the one they use in mainnet. This would allow us to start experimenting with CosmoVisor and also ensure that we catch potential regression issues related to core dependencies like libwasm.so and flushing of config files before we release to mainnet. Because as it stands mainnet is currently the only environment where we can truly test how consensus will behave to changes to the software.

If the price does not crater below its current levels I think it might be an idea to look at Jared suggestion around potentially subsidizing validator test servers to the extend the CP can afford it after covering all essential expenses, to help increase enrollment in the testnet as it could be argued that their reluctance in joining the testnet is mainly that it increases their TCO and lowers their ROI.