[Feature]: Read large ArcGIS layers live, a view at a time (an ArcGIS FeatureSource) #829

Before you start

• I searched the existing issues and the roadmap and did not find a duplicate request.

What problem does this solve?

#764 (merged in #823) reads an ArcGIS FeatureServer or MapServer layer past its record limit by downloading it page by page, up to 100,000 features. That's enough for a small town's parcels or a county's zoning, but not for a large county. Fairfax County publishes 369,542 parcels on ArcGIS Online, and RustGIS reads the first 100,000 by object id, with a note. The map looks complete until you notice parcels missing, and they can be anywhere in the county.

Raising the cap doesn't solve it. Downloading a whole county to look at one neighbourhood is slow, costs memory (100,000 parcels peaked at 2.2 GB natively), and a browser tab's wasm memory tops out at 4 GB.

RustGIS already handles data bigger than memory: a FeatureSource answers "the features in this extent, at most this many", and a layer draws it a view at a time. GeoPackage, FlatGeobuf, GeoParquet, Shapefile, large GeoJSON files and the PostGIS, MySQL and SQL Server tables all work this way. A county parcel table in PostGIS can already be browsed in full. The same table published as an ArcGIS service can't.

Proposed solution

An ArcGIS FeatureSource in rustgis-data (source/arcgis.rs), for layers over a threshold. ArcGIS's query API already speaks the trait's language:

• A view (read): query?geometry=<extent>&geometryType=esriGeometryEnvelope&inSR=4326&spatialRel=esriSpatialRelIntersects&resultRecordCount=<limit>&outSR=4326&f=geojson, paged by resultOffset in object-id order as in [Feature]: Read every feature of an ArcGIS FeatureServer or MapServer layer, past its record limit #764. When the limit is hit, the trait asks for an evenly spread sample rather than the first N. ArcGIS has no direct way to ask for that, so one option is to use the layer's maxRecordCountFactor or quantizationParameters for generalised drawing at small scales. To settle in review.
• Every feature (visit_chunks): page through the whole layer a chunk at a time, so geoprocessing runs on a large layer with bounded memory.
• The browser: follow the remote sources' pattern. A read returns remote::NEED until its pages are fetched, and remote::drive fetches them asynchronously.

Questions to settle before building:

1. When a layer goes live. Above a feature count (the layer's returnCountOnly, one cheap request), always, or as the user's choice in Add From Service?
2. Server load. Every pan becomes a query to someone's county server. That needs a debounce, a cache of extents already read, and a limit on concurrent requests per host (the tile fetcher already has one).
3. Offline and saved projects. A live layer needs the server when a project reopens, as a PostGIS layer does. Should "make a local copy" be offered, using [Feature]: Read every feature of an ArcGIS FeatureServer or MapServer layer, past its record limit #764's download?
4. Selection, the attribute table and editing. These assume rows in memory. They'd behave the way they do for PostGIS layers today, whatever that is for each.
5. Tokens. These come from the address today. With the secret store (Solid ground) and ArcGIS sign-in (Data at the source), the source should take its credentials from there.

This sits in the roadmap's Data at the source theme, next to the ArcGIS sign-in item and deniial00's connections work (#699, #701, #705). I'd like a maintainer's view on the questions above before writing much code.

Estimated scope

Large. rustgis-data (a new source), engine (adding a service layer as a source above the threshold), probably ui-egui (the choice in Add From Service), and tests against the shared fixture server. It adds no dependency or crate. It may affect the .rgis format, depending on how a live ArcGIS layer is saved: possibly as the existing source reference, possibly with new fields.

Alternatives considered

• Raising [Feature]: Read every feature of an ArcGIS FeatureServer or MapServer layer, past its record limit #764's 100,000 cap. This moves the limit without removing it, and every feature still has to be held.
• Joining pages with less memory. This is a separate, smaller issue ([Feature]: Read a service's pages in memory close to the data's size #830). It's worth doing for downloaded layers either way, but it still downloads everything.
• Drawing the MapServer's export images. RustGIS already offers a dynamic map's layers as images (layers=show:<id>). They show the whole county but have no attributes and no analysis.