Imagine this situation:

1. Let's assume we start with our current LearningLoop version, which is version 1
2. Now I introduce a change in the LearningLoop that affects the metadata and that's not backwards-compatible.
3. In principle, I should also increment the LL version to version 2, but I forget about that.
4. If necessary, I adapt current tests to work with my new changes and move on. All tests pass.
5. The changes are merged introduced in a new release.
6. Suddenly we have nodes in the network with the same LL version but different metadata format.

@jMyles @KPrasch Is this a plausible scenario? If so, I propose the following:

• Introduce a new test specific to version 1. This test will include a hard-coded node metadata bytestring, which will be validated by test ursulas. The purpose of this test is to fail if a change in the codebase affects node metadata and the programmer forgets to increment the version.
• When we need to upgrade to version 2, we need to produce a new bytestring.

As an alternative, we can introduce a test that disassemblies node metadata bytestrings of current test ursulas, and tries to validate the format against the current specification (currently, version 1). Perhaps this is even easier. We'd have to be very clear that this test cannot be changed, and that it fails is an indication that the format has changed.