fix(downloadFile): write directly to file using Guzzle's "sink" option

[oleksandr-nc]

This PR transitions our file download logic from using Guzzle's stream => true option to the more memory-efficient sink option, mirroring improvements made in other integrations (e.g., OneDrive Integration).

While stream => true prevents Guzzle from buffering the entire response body in memory upfront, it returns a Psr\Http\Message\StreamInterface. When we iteratively read from this stream (e.g., with fread()), each chunk is copied into a PHP string variable before being written to disk. This creates temporary data duplication in PHP's userland memory for each chunk.

Furthermore, even with stream => true, data passes through various buffering layers:

• The operating system's network buffers.
• PHP's own internal stream buffers.

These, combined with the chunk copied into our PHP variable, contribute to memory pressure during large file downloads, potentially leading to memory_limit issues.

The Guzzle sink option provides a more direct path. Guzzle streams the HTTP response body directly into the provided writable resource (e.g., a file handle) which significantly reduces memory overhead.

[oleksandr-nc]

Unfortunetly, locally I can not reproduce the error from the CI, for me at my local machine this code works..

---

Edited: Looking at this issue this PR will make app incompataible(unless Nextcloud maybe added support for sink from that time) with Server Side Encryption. So feel free to close this PR, but at integration_onedrive I will keep these changes as without sink I constantly get memory exceed error.

[marcelklehr]

mh, looks like we're stuck then, no? either we break sse or we cause OOM. 🤔

[marcelklehr]

Could we use the sink option to download to a temp file and then stream copy to the encrypted file?