[Refactor]: remove xmltree from the AsterDrive XML stack

[AptS-1547]

Context

AsterDrive currently depends on xmltree for WebDAV DOM construction, WebDAV request/dead-property handling, LOCK owner persistence, DeltaV responses, WOPI discovery, and Tencent COS XML parsing.

The WebDAV security fix in #410 added Forge-owned non-recursive XML validation before untrusted XML reaches xmltree, but xmltree still uses unbounded recursive DOM construction and has no element-depth limit. The upstream crate documentation only warns about memory use for large XML documents.

Goal

Remove the production and test dependency on xmltree and use maintained, bounded XML paths owned by AsterForge or the relevant product boundary.

Proposed scope

• Replace WOPI discovery and Tencent COS XML parsing with typed quick-xml readers where the XML schema is known.
• Replace WebDAV request parsing with Forge validation plus event-based or typed parsing.
• Replace WebDAV response construction with quick-xml::Writer or a small product-owned writer boundary.
• Replace DavLock.owner: Option<Box<xmltree::Element>> with an owned product representation or validated XML bytes.
• Preserve dead-property XML, namespaces, LOCK owner round-tripping, DeltaV response compatibility, and COS/WOPI behavior.
• Remove xmltree from Cargo.toml, Cargo.lock, production code, tests, and crash-probe comments.

Constraints

• Keep Forge as the owner of reusable XML safety validation.
• Do not replace xmltree with another unbounded recursive DOM parser.
• Keep body-size limits, depth limits, DTD/ENTITY rejection, and malformed-document handling at every untrusted or remote XML boundary.
• Split the migration into reviewable phases instead of changing every XML path in one large patch.

Acceptance criteria

• rg -n "xmltree::|use xmltree|xmltree =" src tests Cargo.toml Cargo.lock returns no production or test dependency.
• WebDAV full integration tests pass, including dead properties, LOCK owner round-trips, DeltaV, partial COPY/MOVE, and deep XML rejection.
• WOPI discovery and Tencent COS XML tests pass.
• Forge XML safety tests remain the shared boundary regression suite.
• No public API or wire-format regression for WebDAV, WOPI, or COS integrations.

Related

• Fix/security issue webdav remote node #410 WebDAV and remote-node security fix
• Upstream investigation draft is kept locally and has not been submitted to xmltree-rs.

[AptS-1547]

Performance investigation

I ran an isolated release-mode microbenchmark against the versions currently resolved by AsterDrive:

• xmltree 0.12.0
• xml 1.3.0 (xml-rs, used underneath xmltree)
• quick-xml 0.41.0
• Rust 1.97.1, aarch64-apple-darwin
• Criterion: 1 s warm-up, 3 s measurement, 40 samples

The benchmark consumes element names, attributes, decoded/normalized attribute values, decoded/unescaped text, and namespaces rather than only tokenizing raw bytes. xmltree results include DOM construction followed by a full tree walk.

Parsing results

Synthetic workload	Input	xml-rs events	quick-xml events	quick-xml namespace events	xmltree DOM + walk
Small WebDAV PROPFIND	197 B	6.69 us	0.386 us	0.748 us	6.98 us
WOPI discovery, 256 apps x 4 actions	139 KiB	2.34 ms	0.320 ms	0.465 ms	2.70 ms
WebDAV multistatus, 1,000 responses	337 KiB	10.56 ms	0.608 ms	0.947 ms	13.80 ms
XML nested to depth 64	1.15 KiB	49.71 us	5.27 us	8.03 us	59.53 us

Across these inputs:

• plain quick-xml event parsing was about 7.3x-17.4x faster than xml-rs;
• namespace-aware quick-xml was about 5.0x-11.1x faster than xml-rs;
• namespace-aware quick-xml was about 5.8x-14.6x faster than xmltree DOM construction and traversal.

An important detail is that removing only the DOM while retaining xml-rs would leave most of the CPU cost in place. Direct xml-rs event parsing was only about 4%-31% faster than xmltree in these workloads. The larger performance change comes from moving the parser from xml-rs to quick-xml, while removing the DOM primarily improves ownership, depth handling, and memory use.

Current WebDAV pipeline versus the proposed pipeline

The current untrusted WebDAV path performs two passes:

1. Forge quick-xml safety validation;
2. xmltree/xml-rs parsing and recursive DOM construction.

I compared that with a conservative migrated path which still keeps the separate Forge safety pass, followed by namespace-aware quick-xml event parsing:

Workload	Current: safety + xmltree	Migrated: safety + quick-xml::NsReader	Improvement
Small PROPFIND	7.85 us	1.03 us	7.6x
multistatus, 1,000 responses	14.39 ms	1.33 ms	10.8x
Depth 64 XML	64.00 us	10.83 us	5.9x

This means the migration does not need to weaken or merge the Forge-owned validation boundary to obtain a material CPU improvement.

Response writer results

For a synthetic multistatus response containing href, propstat, prop, property values, and status elements:

Responses	xml-rs writer	quick-xml::Writer	xmltree DOM + write
10	8.31 us	4.52 us	17.37 us
1,000	0.812 ms	0.441 ms	2.21 ms

quick-xml::Writer was about 1.84x faster than the xml-rs writer and about 3.8x-5.0x faster than constructing and serializing an xmltree DOM.

Peak memory

Peak RSS was measured in separate release-mode processes with getrusage(RUSAGE_SELF). The input/output Vec is included in each result.

Parsing a 50,000-response synthetic multistatus document (17.6 MiB input):

Path	Peak RSS
xml-rs events	about 33.7 MiB
namespace-aware quick-xml events	about 32.9 MiB
xmltree DOM + walk	about 711.5 MiB
Forge safety validation + xmltree	about 717.5 MiB

Constructing a 50,000-response synthetic XML document:

Path	Peak RSS
xml-rs writer	about 14.0 MiB
quick-xml::Writer	about 14.2 MiB
xmltree DOM + write	about 313.2 MiB

The event readers and writers stay close to the size of the input/output buffers, while the DOM representation amplifies memory through independently allocated element names, namespace data, attribute maps, child vectors, text strings, and node enums.

Interpretation for this issue

These are parser/writer microbenchmarks, not end-to-end WebDAV latency measurements. Authentication, database queries, permission checks, storage access, and network transfer will dominate many real requests, so a 5x-17x parser improvement must not be presented as the same improvement for the complete HTTP request.

The results nevertheless strengthen the migration case:

• fixed-schema WOPI and COS parsing can avoid retaining irrelevant document structure;
• WebDAV request parsing can keep the Forge validation boundary and still remove the slower recursive second pass;
• large WebDAV/DeltaV responses can avoid building the complete response DOM before serialization;
• dead properties and LOCK owner XML remain the compatibility-sensitive parts and should use a validated owned representation rather than another unbounded recursive DOM;
• the primary gains are bounded parsing, substantially lower peak memory, and lower XML CPU cost; binary-size reduction remains secondary.

The benchmark was kept outside the product checkout and did not modify AsterDrive source files.