[support-bundle] include for large log files

[papertigers]

@wfchandler noticed an error in a collected support bundle where we failed to copy a large (31GB) log file.
We need to turn on large file support if we wish to include these files.

03:21:25.519Z ERRO SledAgent: Failed to write service log to zip file: Large file option has not been set
    file = sled-diagnostics/src/logs.rs:725
    log = /pool/ext/1f91451d-a466-4c9a-a6e6-0abd7985595f/crypt/debug/.zfs/snapshot/sled-diagnostics-fJX7Qry22VZX/oxz_crucible_76fe2161-90df-41b5-9c94-067de9c29db1/oxide-crucible-downstairs:downstairs-430d51d9-bad0-4dda-bd3b-548f176a9b51.log.1754362713
    service = crucible-downstairs
    sled_id = 2c33e8ef-ae07-4191-804d-52a1840ce53c

[papertigers]

In this case @wfchandler noted the log file is mostly duplicate log lines and would likely compress nicely. My concern is a log file where this is not the case and we have to burn CPU cycles compressing it and then transferring it over the network to later be unpacked.

I wanted to post this is a draft for feedback because regardless of how well it compresses the final result gets decompressed on the other side and we still use the default compression algorithm for the final zip file I believe.

[smklein]

This is not a blocker for this PR , but it has me wondering:

We basically want to pull out the contents of the "zipfile from the sled-agent" and just rename things within the user-visible zipfile that we're creating. I wonder if this would be possible with a slightly more advanced version of zip, that lets us transfer the "contents" of zipfiles around without unpacking them.

(Basically, move the contents of a zipfile entry to a new name, if the compression scheme is an exact match)

This seems like a dangerous operation, but could be a possible optimization if this is taking a while. It's potentially eating a chunk of disk space, but as long as we're using streaming operations to write to the zipfile, I think it's not (currently) consuming 30+ GiB of memory.

TL;DR: this current implementation is fine with me, as long as it doesn't have too-bad performance implications.

[smklein]

Also: I wonder if we should pick an explicit compression scheme here, so we aren't at the whim of zip changing defaults.

E.g., we expect it'll be supported by customers, maybe we just pick zstd-3 here too

[wfchandler]

I think it's probably not a good idea to use zstd for the customer-accessible file because the standard zip tools on all major platforms don't support it. How would we access the file on Illumos, for example?

[smklein]

according to https://docs.rs/zip/latest/zip/write/struct.FileOptions.html I think the default is "Deflate", and the level is either 24 or 6? https://docs.rs/zip/latest/zip/write/struct.FileOptions.html#method.compression_level

Good point re: zstd - just want to make sure an update of the zip crate doesn't change this for us

[wfchandler]

Ah yeah, agreed it makes sense to define which algorithm we want to use.