zcash_client_sqlite: init_blocks_table and put_sapling_subtree_roots conflict

[str4d]

In #831, zcash_client_sqlite::wallet::init::init_blocks_table was modified to insert the nodes of the given wallet birthday frontier into the ShardTree:

librustzcash/zcash_client_sqlite/src/wallet/init.rs

Lines 320 to 338 in 4d5dc28

	if let Some(nonempty_frontier) = block_end_tree.to_frontier().value() {
	let shard_store =
	SqliteShardStore::<_, sapling::Node, SAPLING_SHARD_HEIGHT>::from_connection(
	wdb.conn.0,
	SAPLING_TABLES_PREFIX,
	)?;
	let mut shard_tree: ShardTree<
	_,
	{ sapling::NOTE_COMMITMENT_TREE_DEPTH },
	SAPLING_SHARD_HEIGHT,
	> = ShardTree::new(shard_store, PRUNING_DEPTH.try_into().unwrap());
	shard_tree.insert_frontier_nodes(
	nonempty_frontier.clone(),
	Retention::Checkpoint {
	id: height,
	is_marked: false,
	},
	)?;
	}

Meanwhile, as the first step to the non-linear sync process being added in #872, we need to fetch the subtree roots before scanning and add them to the ShardTree using the WalletDb::put_sapling_subtree_roots method added in #861:

librustzcash/zcash_client_sqlite/src/lib.rs

Lines 676 to 694 in 4d5dc28

	fn put_sapling_subtree_roots(
	&mut self,
	start_index: u64,
	roots: &[CommitmentTreeRoot<sapling::Node>],
	) -> Result<(), ShardTreeError<Self::Error>> {
	let tx = self
	.conn
	.transaction()
	.map_err(|e| ShardTreeError::Storage(Either::Right(e)))?;
	put_shard_roots::<_, { sapling::NOTE_COMMITMENT_TREE_DEPTH }, SAPLING_SHARD_HEIGHT>(
	&tx,
	SAPLING_TABLES_PREFIX,
	start_index,
	roots,
	)?;
	tx.commit()
	.map_err(|e| ShardTreeError::Storage(Either::Right(e)))?;
	Ok(())
	}

These appear to conflict: when testing #872 on mainnet, put_sapling_subtree_roots returns an insertion error.

[str4d]

When the added logic from init_blocks_table is commented out, the issue goes away. My initial guess is that this is caused by a bug in ShardTree::insert_frontier_nodes, where it is inserting a leaf into the cap corresponding to a subtree that is not complete.

[str4d]

The problem was that put_shard_roots pretends the subtree roots are leaves of a DEPTH - SHARD_HEIGHT tree so it can update the cap, but the Sapling tree Merkle hash is level-dependent.