[mahach666]

Refs #48

In a file without its own class schema (Revit 2020 and 2022) whose partition streams are read by their framing, the block reader now reads the records of the project's own block as the framing lists them, in their current copy, instead of scanning the stream for anything that looks like a block.

What changes

• BlockParser.ParseBlock is the body of the scan loop, so a framed record and a scanned block go through the same code.
• RvtFileReader.ParseFramedBlocks feeds every framed record but the channel-101 headers (owner 1 to uint.MaxValue, at least 18 bytes) to it, a record that runs into the next segment included (PartitionFraming.Framed.Bytes copies it out of its segments). The chunks of the partition streams are then not scanned; every other chunk is scanned as before.
• The blocks of the documents of loaded families, whose element ids repeat project ids, are no longer read as project elements.
• Shortcut: the geometry of a record that runs into the next segment or holds more than BlockParser.MaxBlockSize (1,000,000) bytes is not decoded, as the scan never reached it. On the largest test file ten such geometry records of 0.7 to 0.9 MB took 28 to 180 s each in the geometry decoder and changed nothing in the output.

Measured

26 project files, export of this branch against the commit it starts from (the head of #190):

• IFC and compact JSON identical in 25 files.
• The export report differs in 22 files: the elements it counts (ids that only a family document held are no longer counted) and the category of ids the Revit API does not return. For ids the API returns, the category agrees with Revit as often as before.
• One architectural file: 8 sketch lines change their length and 14 walls the name of their type. These elements keep two copies from different increments that the increment table does not tell apart; the reader now takes the other copy. Against Revit 2022: 5 of the 8 lengths are now right, 3 were right before (6465 of 6482 sketch lines right, 6463 before); the type name of the 14 walls is wrong before and now.
• Element list of RvtDocument, one test file (59,201 entries before), checked against the elements Revit 2022 returns for each id: the 8,135 elements Revit returns are unchanged (category, type, name, parameters, references). Of the entries Revit does not return, 49 without a category are gone and 50,738 change, mostly by losing parameters (3,737,513 parameters in all before, 3,161,540 now); 16,373 change their name. Two snapshot tests in ApiTests.cs count names over that list and now include two such entries (ids 172544 and 265364), so their expected values are updated.
• Time: export of the largest file 657 s (IFC) against 806 s before; without the shortcut it was about twice as slow as before.

Not covered

• Which of two unresolved copies is current (record routing); this is what moves the 8 lines and 14 walls.
• A geometry decoder that is linear in the block size, after which the geometry of the large and crossing records can be decoded.
• No test that the chunks of the partition streams are left out of the scan; covered only by the export comparison above.

Verification

• New tests in OwnElementClassTests: a project record across two segments is read and a family block is not; the geometry of a crossing record and of a record over the size limit is not queued.
• Full suite net8.0 before the update of the two snapshot tests: 10818 tests, 10667 passed, 141 skipped, 10 failed: the 8 bounding-box tests that fail on main and the two snapshot tests above. After the update ReferenceApiTests and OwnElementClassTests pass (43 of 43).
• After the rebase onto main (Seed legacy type-level material relation GlobalIds from material identity #193, Add --strict option and exit code 6 for partial reads #194): the classes above and the test classes those PRs touched, with the partition framing and block parser tests, pass (322 passed, 2 skipped, 0 failed). The full suite and the export comparison ran on the branch before the rebase.
• net10.0 not run.