Revisit all apps/examples and decide how to _demonstrate_ ABCI++

[sergio-mena]

Summary

The current status of abci++ branch does not use ABCI++ in an advanced way. The App persistent_kvstore is populating the two fields of the vote extension with the validator's address. Not clear to me what the use case is, other that testing non-nil vote extensions.

Problem Definition

We may decide to extend one (or more) of the apps to make an advanced use of ABCI++.
Or we may decide to add a new app that render itself as a natural use case for ABCI++.
Bear in mind this might have to be split into two parts if vote extensions are postponed.

Dependencies

None

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[cmwaters]

Before tacking this issue, I would like to first close this one: #5790. Specifically I would like to remove the kvstore and just have the persistent kvstore. Thus, Tendermint would only have two ABCI applications: persistent kvstore (or we can just call it kvstore) and the e2e app. Both of these should use ABCI++ but likely to varying degrees (we may want to be a lot more thorough in the e2e test suite)

[sergio-mena]

Still, we might need to come up with a different App that kind of demonstrates the need for ABCI++ features. Hard for me to say at this point

[cmwaters]

Yes we'll obviously look into this in more detail after getting most of the implementation done. I just won't to avoid unnecessarily increasing the maintenance burden with yet another ABCI implementation if we can

[sergio-mena]

Shall we add #5790 to the ABCI++ project?

[sergio-mena]

Thanks  @williambanfield for rasising the issue that this task should also involve refactoring/rethinking/revamping/extending the builtin Tendermint tutorial