NOT TO BE MERGED: An example of 1.4 failure when hitting unknown content

[vladsud]

Test to demonstrate that a simple creation of a DDS will trip 1.4 client, as ID compressor is involved in such case (if it's enabled in container).

The purpose of having ID compressor in runtime is that it can be used by runtime (and runtime customers) if it's present. DDSs & data store creation code will leverage that for creation of short IDs, as it's known that usage of long IDs results in substantial increase of summary sizes (1.5-2.0x compared to using short IDs, mostly due to GC blob) and snapshots (I'd estimate - 5% for Loop payloads). We can disable such functionality directly (i.e. have an extra knob that instructs that particular path not to use ID compressor even if it's present in runtime), but that sort of defeats the purpose of having ID compressor at runtime (and controlling its availability via its own knob), and it does not protect against some other feature of taking dependency of ID compressor.

There is also a risk that someone will use 2.0 FF packages and will start using SharedTree (with ID compressor) but will accidently try to open such document in 1.4. This may result in a failure like this test shows. It may also result a corruption of a document if ID compressor ops are not present in an op tail - 1.4 summarizer will happily drop ID compressor blob from the summary, breaking eventual consistency of a file.

Test results (saving you some clicks): https://dev.azure.com/fluidframework/public/_build/results?buildId=259650&view=ms.vss-test-web.build-test-results-tab&runId=5582815&resultId=101480&paneView=debug