Lift line vertex/strip count limitations

[Wumpf]

What

• follow-up of Lift point cloud size limitations #5192
• Fixes Remove limit on line and point count #3076
• Fixes API to expose viewer limits to users #4844
  • technically there's still limits (see Lift point cloud size limitations #5192 ) but they are machine dependent making this relatively hard to query. Overall I'd argue we removed the previous limits so there's no need for this in the original sense.

(note that we haven't spend a lot of time optimizing the collection of lines, large amounts of lines don't perform all that well so far)

Applies the same principles as on the previous PR that fixes the point cloud limits.
The key difference here is that we use lines in a lot of places, making this a bigger refactor than originally assumed.

---

The need to know both strip & vertex count for lines ahead of time is a bit problematic and isn't always as easy as it was with points. We err on the side of generating more draw data bundles, but to limit this (a single drawdata for a single line is extremely wasteful as we have to allocate a bunch of textures, buffers, bind groups, etc. etc.) I had to introduce LineDrawableBuilderAllocator which is a very simplistic Vec-like allocator (minus the increase in size) for LineDrawableBuilder (previously called LineStripSeriesBuilder).
I'm not super happy with this construct overall, but it's the best I could come up with in the short-term and things seem to be fairly robust and at least not overly complicated.

In the future it would be nice to reconcile LineDrawableBuilderAllocator and LineDrawableBuilder into a single construct, likely still with the limitations that the size of a batch (think named unit with a transform) needs to be known ahead of time, which is practically always the case!

---

Second iteration: There's now DataTextureSource (ideas for better names?) which is essentially a thing where you can throw data in and get a data texture out! It handles all the copies and dynamic sizings for you. This makes everything awesome because now we can handle reserve call just as an optimization without requiring them and without being on a bad path if you don't! <3

Checklist

• I have read and agree to Contributor Guide and the Code of Conduct
• I've included a screenshot or gif (if applicable)
• I have tested the web demo (if applicable):
  • Using newly built examples: app.rerun.io
  • Using examples from latest main build: app.rerun.io
  • Using full set of examples from nightly build: app.rerun.io
• The PR title and labels are set such as to maximize their usefulness for the next release's CHANGELOG
• If applicable, add a new check to the release checklist!
• Test misc examples on WebGL
• Test misc examples on WebGPU

• PR Build Summary
• Docs preview
• Examples preview
• Recent benchmark results
• Wasm size tracking

[emilk]

Calculating the number of lines needed beforehand is quite annoying and error prone.

I think it makes sense for the big stuff (when a user has logged line segments), but for smaller stuff (camera ray lines, bounding box edges, …), I wonder if we could instead use a dynamic mode for the line allocator, i.e. that collects in RAM and push to VRAM once finished.

[Wumpf]

I wonder if we could instead use a dynamic mode for the line allocator, i.e. that collects in RAM and push to VRAM once finished.

yes, probably. But do we really want to fork the linebuilder right now :/

[Wumpf]

Hmmm actually.. maybe we can make the regular line builder growable by having several cpu-write-gpu-read buffers in there 🤔
We just need to be careful about this texture copy business. But conveniently the line build hasn't been ported all the way to the cpu-write-gpu-read belt yet

[Wumpf]

these three functions were moved without change other than a todo note on their now short-lived fate

[Wumpf]

Alright! This is now worlds better than before and will make putting everything else in points & lines onto a cpu-write-gpu-read buffer a breeze!!

[emilk]

I love it!

But the main invariant is not always guaranteed to be kept, so this is buggy

[Wumpf]

I wish there was an easy way to write unit tests for this new allocator without shimming all wgpu calls 🤔

[emilk]

LGTM, but I added checkboxes to explicitly test on both WebGL and WebGPU