docs(examples): add carbon-account-app

[petermetz]

Description

It would be great for us to help out the Climate Action SIG with the important work that they are doing and at the same time expose ourselves (our designs) to real-world problems/use cases that developers will use Cactus to solve.
The idea here is to have a full-fledged example application doing the same thing that's being done in the pre-existing codebase that Si Chen demoed to us during the maintainer's call on the 19th of January in the year 2021 [1] and based on the additional information provided later via emails: [2], [3]

https://docs.google.com/document/d/1jiPaEoa-lBwn5_w4HVj1_ItdUV-DkFU93guSTMqtOu8/edit?ts=601c8205

[1] 2021-01-19 Meeting Notes: https://wiki.hyperledger.org/display/cactus/2021-01-19+Meeting+Notes

[2] [Hyperledger Cactus] Using Cactus to connect Fabric and Besu: https://lists.hyperledger.org/g/cactus/message/204?p=,,,100,0,0,0::relevance,,si+chen,100,2,0,78464157

[3] testing the Climate SIG Fabric-Ethereum connection: https://lists.hyperledger.org/g/cactus/message/217?p=,,,100,0,0,0::Created,,,100,2,0,80392158

[4] https://wiki.hyperledger.org/display/CASIG/Emissions+Tokens+Network

[5] http://emissionstokens.opentaps.org/

Acceptance Criteria

1. Example is end to end and containerized so that we discover issues that a developer would face who actually has to deliver a working application not just some partial demo/PoC
2. Changes that were necessary (if any, likely many) to Cactus while developing the example are broken into separate commits and submitted as independent pull requests prior to submitting the final PR containing the example itself. This will provide us with a chance to review changes in the core and review those independently from the examples itself (of which the review should be much simpler/straightforward since it's just an example not something that changes actual Cactus packages)
3. Solution should be approved by the CA SIG as something that appears to be usable by them (doesn't need to actually replace their existing implementation but that would be the absolute best of course)
4. A set of good first issues are defined that are all specific to the CA SIG work of ours

cc: @opentaps @takeutak @sfuji822 @hartm @jonathan-m-hamilton @AzaharaC @jordigiam @kikoncuo

[sichen1234]

Just a quick update to the instructions from https://lists.hyperledger.org/g/cactus/message/217:

With our recent changes, the api to record tokens for emissions on the Fabric channel now takes a comma separated list of the ID's of the Fabric records, like on this screenshot:

You can get them as the _ids from Couchdb.

Here are some screenshots of the results

[sichen1234]

An update: We've deployed the Fabric app to production on Amazon Kubernetes and used it to create tokens on xDai (layer 2 ethereum network). We found that the integration was not very stable. There were a lot of time outs on the ethereum side, so our simple code thought the transaction failed when in fact it succeeded but much later. We're setting up our own xDai node to see if that improves things.

What this means is that an integration between Fabric and a public network should probably:

1. Parse returning error messages and handle them differently
2. Instead of a success/fail right away, poll the public network to see if the transaction in fact ran, then update Fabric.
3. Perhaps a local node of the public network should be considered a "best practice"

[petermetz]

@sichen1234 Great that you mention this because this is where Cactus could shine! Our Besu connector has a parameter called consistencyStrategy 1 2 where you can control if you want the connector wait for either

1. just the local node's tx pool confirming your tx
2. wait until the chain itself added the tx as part of a block and then wait an additional number of blocks confirmed as an extra insurance for transaction finality

So it sounds to me like this problem could be solved by using the Besu connector and I'll look into it deeper as I continue with my work on this task.