unify monorepository

[brenzi]

Why a monorepo?

Pro:

1. it is cumbersome to merge pallet changes with PR's on multiple repos. We usually first test with unit tests in pallets repo, but then we need integration tests with bot-community script which requires a PR in the encointer-node repo, but CI can't pass before the pallet PR is merged unless we hack in an intermediate cargo patch which is just ugly.
2. no_std clashes caused by pallets can sometimes only be detected after integration in to runtime
3. We want to align business logic on solochain and parachain testnets and mainnet. In the best case, we align spec-versions for our respective runtimes. So keeping all runtimes in the same repo with the same spec version makes sense
4. We now follow polkadot release branch dependencies (should be done even for solochain substrate dep), so upgrades would be more straightforward if all was in the same repog
5. CI for parachain gets easier: [CI] run same integration tests as node encointer-parachain#140
6. It is often not obvious if an issue should be submitted to pallet, node, or parachain repo

Con

1. pallet PRs, which are currently very simple, will take longer to merge as they demand simultaneous integration into the node/parachain (but that's how continuous integration should be....)
2. bumping substrate might be a bit more complicated, as we need update the node & the parachain

monorepo name

suggestion:

1. create fresh repo encointer/encointer
2. archive encointer-node, pallets, encointer-parachain and (before archiving ;-) redirect in README)

alternative ideas:

• encointer/backend
• encointer/platform
• encointer/network

what repos to merge

• encointer-node
• encointer-parachain
• pallets
• (worker)...later

It may make sense to move community specfiles out of our code repo into its own repo encointer/communities as there is no depenmdency on this data from within the monorepo

what not to include in a monorepo and why

• mobile app: Has its own release cycle which is loosely coupled with our runtimes
• encointer-js: Is not a dependency of anything else in the monorepo, so we may want to leave this separate

open questions

• bazaar integration tests are still a mess (see intermediate work business/offering data models and helper scripts #174). May be better to separate e2e testing (integrate functionality into bot-community.py) and helpers (register-business, register-offering... in scripts folder)
• similar decision to take for democracy stuff: include democracy e2e into bot-communities.py?

monorepo structure

client/
client/encointer-api-client-extension

tests (e2e testing of parachain and solochain)
tests/py/  (only what is needed for integration testing, no production tools -> they should go to ./scripts)
tests/py/encointer (formerly py_client)
tests/py/tools/faucet.py, phase.py
tests/py/bot-communities/bot-communities.py (to be split into parts to be extendable)

pallets/

solochain/node (rename crate to `encointer-solochain`)
solochain/runtime
solochain/chainspecs

parachain/node (collator: rename crate to `encointer-parachain`)
parachain/runtime/encointer
parachain/runtime/launch
parachain/runtime/common
parachain/chainspecs

sidechain/node (future place for "worker/validateer")
sidechain/runtime (sgx-runtime)

scripts/* + voucher.py batch.py endorse dump-accounts dump-balances .....

communities repo structure

./*.json
assets/leu.zuerich
assets/decoded.berlin
assets/decoded.buenosaires
assets/EdisonPaula
assets/Adriana