Compress enormous metadata section by 50% while making it friendlier

[JaroslavTulach]

Various META-DATA related issues

• ### META-DATA ### get duplicated (on external edits) and yield Unexpected expression #7921
• Exchange metadata between Windows & Unix complicated because of EOL #7994
• Instrumenter to observe behavior of nodes with UUID #7833 (comment)
• Less strict identification of METADATA header. #7843

indicate the META-DATA section composes a major problem and a bottleneck in the stability of the whole parsing and editing infrastructure. In addition to that and independently of that the format of metadata is extremely verbose and deserves redesign. Instead of:

[{"index":{"value":127},"size":{"value":3}},"00000000-aaaa-bbbb-0000-000000000000"],

we should be writing:

[127,3,"00000000-aaaa-bbbb-0000-000000000000"

e.g. shorten each record by almost a half. Please modify the parser to support new, shorter format and make it more bulletproof.

Tasks

Preview Give feedback

1. Support shorter UUID record in metadata
2. Avoid ### META-DATA ### get duplicated (on external edits) and yield Unexpected expression #7921 by prefixing all metadata by four spaces - e.g. turn them into comment
3. Support multiline, human friendly format - Instrumenter to observe behavior of nodes with UUID #7833 (comment)

[somebody1234]

an alternative solution would to be to extract the metadata to separate files so that they become regular JSON, which can then be consumed using a regular JSON parser. not sure whether there are any major downsides to this approach though

[jdunkerley]

@Frizi and I also discussed this change - we should make it, but we need to make sure we can still read the old format as well, and the change must work in both the new and old IDEs.

[JaroslavTulach]

an alternative solution would to be to extract the metadata to separate files so that they become regular JSON,

Maybe, but my PR #7683 is blocked and I need (dirty) fix immediately, not a complete architecture rewrite in weeks.

which can then be consumed using a regular JSON parser. not sure whether there are any major
downsides to this approach though

I remember discussing that in the past and there was some reasoning behind having UUIDs at the end of the file. Any comment @wdanilo, @kustosz?

[JaroslavTulach]

Obsolete if #9257 gets implemented.