[#103] 🐛 - Replace deprecated ZSTDgetDecompressedSize with ZSTDgetFrameContentSize

[efraespada]

Summary

• Replaced deprecated ZSTD_getDecompressedSize() with ZSTD_getFrameContentSize() across all platform implementations (iOS, macOS, Linux, Windows, Android, CLI) and in generated Dart bindings.
• Preserved existing fallback behavior when the frame content size is unknown or errors (e.g., using the previous fallback logic such as deriving a size from compressedSize when usable).
• Do not vendor or add another copy of the zstd library; continue using the repository’s in-tree zstd sources and build setup. The update leverages the existing ZSTD_getFrameContentSize API already present in the codebase.
• Aligns with zstd guidance that ZSTD_getFrameContentSize() should be used in place of the deprecated ZSTD_getDecompressedSize().

---

🎯 Related Issues / Tickets

• Closes 🐛🧑‍💻 - Replace deprecated ZSTDgetDecompressedSize with ZSTDgetFrameContentSize #103
• Related to bugfix/replacing-deprecated-size-function #102

---

🧩 Scope of Changes

• Added:
  • None
• Updated:
  • Platform implementations (iOS, macOS, Linux, Windows, Android, CLI) to call ZSTD_getFrameContentSize instead of ZSTD_getDecompressedSize.
  • Dart/FFI bindings that invoke the zstd API from Dart to use ZSTD_getFrameContentSize.
• Removed:
  • None
• Refactored:
  • None

---

🛠️ Technical Details

• Replaced all call sites of ZSTD_getDecompressedSize with ZSTD_getFrameContentSize in platform code and generated bindings.
• Updated handling logic to account for:
  • Normal sizes returned by ZSTD_getFrameContentSize.
  • ZSTD_CONTENTSIZE_UNKNOWN as a potential result, and in such cases falling back to the previous sizing heuristic.
  • ZSTD_CONTENTSIZE_ERROR as a potential result, and in such cases falling back to the previous sizing heuristic.
• Maintained the project’s approach to not vendoring or duplicating zstd; all changes rely on the existing in-repo zstd sources and build integration.
• Optional exposure of ZSTD_CONTENTSIZE_* constants in bindings remains available for clarity, but usage can be adjusted as needed by the binding code.

---

🔍 How to Test

1. Build and run the macOS sample app to ensure the project compiles and the UI behaves as before.
2. Run all platform builds (macOS, iOS, Linux, Windows, Android, CLI) to verify the bindings compile and link correctly.
3. Exercise decompression paths with a mix of known-good frames and corner cases:
   • Regular frames where ZSTD_getFrameContentSize returns a valid size.
   • Frames where ZSTD_getFrameContentSize returns ZSTD_CONTENTSIZE_UNKNOWN; verify fallback behavior.
   • Frames where ZSTD_getFrameContentSize returns ZSTD_CONTENTSIZE_ERROR; verify fallback behavior.
4. Run the repository’s test suites:
   • Unit tests (zstandard_test.dart and related platform tests).
   • Integration tests that exercise the Dart bindings and native calls.
5. Search the codebase for any remaining ZSTD_getDecompressedSize usage to ensure all call sites have been migrated.

---

🧪 Test Coverage

• Unit tests
• Integration tests
• End-to-end (E2E) tests
• Manual testing only (explain why)

---

📈 Performance Impact

• No measurable impact
• Minor improvement
• Minor impact expected due to API call change; size retrieval path is functionally equivalent after migration

---

🚀 Deployment Notes

• Requires database migration
• Requires environment variable changes
• Requires feature flag toggle
• No special deployment steps

Details:

• The change is limited to API usage and binding layers; no runtime configuration changes required.

---

🔒 Security Considerations

• No security impact
• Input validation changes
• Authentication / authorization changes
• Sensitive data handling changes

---

📝 Notes for Reviewers

• Please verify all platform bindings (iOS/macOS/Linux/Windows/Android/CLI) and the Dart FFI layer have been migrated from ZSTD_getDecompressedSize to ZSTD_getFrameContentSize.
• Confirm that the fallback logic remains correct when ZSTD_getFrameContentSize returns unknown or error codes.
• Ensure the repository’s existing zstd integration remains intact (no inadvertent vendoring changes).

---

✅ Breaking Changes

• None