Synchronizer.proposeShielding crashes when there are insufficient funds to shield

[str4d]

In #1382 (specifically in 84ac625) we adjusted Synchronizer.proposeShielding to return null when there are either no funds to shield, or they do not meet the shielding threshold (equivalent to the Rust type Option<Proposal>). However this only altered the API, as the FFI still always created a proposal; the backend changes need to be bundled together separately into binary releases of the -ffi backend.

When the -ffi backend was updated to enable zcashlc_propose_shielding to return an optional proposal, the FFI representation was not hooked up to ZcashRustBackend.proposeShielding at all.

The problem is in this code:

zcash-swift-wallet-sdk/Sources/ZcashLightClientKit/Rust/ZcashRustBackend.swift

Lines 735 to 741 in 31a5848

	@DBActor
	func proposeShielding(
	account: Int32,
	memo: MemoBytes?,
	shieldingThreshold: Zatoshi,
	transparentReceiver: String?
	) async throws -> FfiProposal? {

zcash-swift-wallet-sdk/Sources/ZcashLightClientKit/Rust/ZcashRustBackend.swift

Lines 760 to 764 in 31a5848

	return try FfiProposal(contiguousBytes: Data(
	bytes: proposal.pointee.ptr,
	count: Int(proposal.pointee.len)
	))
	}

This attempts to construct a Data from a null pointer, when it should instead check for nullability and then either return null, or construct the Data from the known-non-null pointer.

The bug has been observed very infrequently, most likely because wallets generally only try to shield when there are any funds at all, and in that case the funds are most likely non-trivial in value (and thus above the shielding threshold).

[str4d]

#1424 incorrectly resolved this issue. It throws an error when a nil proposal is encountered, instead of returning nil. This results in an error being shown to the user, when instead the wallet should get from the SDK a nil proposal and interpret that as "there are insufficient funds to meet the shielding threshold".