Reproduce #782 as an end-to-end test case

[adaszko]

Reproduces (with a failure because it's still unresolved) the issue radicle-dev/radicle-link#782

Open questions/decisions:

• Whether we want to keep the monorepo contents that trigger the issue within this repository, as it adds (acceptably IMO) to to this repo size. Then again, it's the most convenient option compared to fetching it from external sources.
• It needs to be added to CI on this repo, but since the test is going to fail anyway, I held that back for now.

How it works: The Python code launches 2 separate org-node processes and sets up the 2nd one (the replicator) to replicate from the 1st one (the bootstrap). Whenever it sees a log entry of severity ERROR on either of the stdouts of the two, it fails the test. After it infers (based on logs) that the replication completed, it does asserts on the existence of relevant files that should be present after replication.

The README file has instructions on how to run the test.

This style of writing tests should be flexible enough to reproduce many of the issues rounded up in radicle-dev/radicle-upstream#2449 (comment)

[cloudhead]

This is really great! I wonder though if it belongs here, vs. a dedicated repo? Since the changes that would break or fix this test will usually be in the underlying protocols.

[adaszko]

This is really great! I wonder though if it belongs here, vs. a dedicated repo? Since the changes that would break or fix this test will usually be in the underlying protocols.

Thanks! I think the classic rule of "late bugs cost more to fix" applies here. Ideally, we would want to execute end-to-end tests on each PR, even before merging to master to see if a PR introduces a regression. The PR may be a change exclusive to the client services code, or it may be a version bump of librad and friends that it depends on. In both cases, it's valuable to see right away if something broke. If those tests land in a separate repository, that's going to be harder to pull off.

Another point is that those tests aren't limited to testing the protocol. They may as well check if org-node produces proper outputs on the newly introduced built-in http server.

[adaszko]

I've managed to minimize the input monorepo to just two repos: hnrkjajuucc6zp5eknt3s9xykqsrus44cjimy andhnrkbtw9t1of4ykjy6er4qqwxtc54k9943eto. If I remove the former, the test case passes. The latter can't be removed because it wouldn't be replicated and it is at the replication of it that the error occurs, so I think the test case is small as it gets now.

As an aside: tarring and even compressing didn't make a substantial difference, so I've forgone it because it makes working with code harder at no noticeable gain.