Allow blocks with empty batches

[PhilippGackstatter]

Allow blocks with empty batches so we can build new blocks in the node even if no transactions or batches are available.

Also clarifies comments in the proposed batch.

Consistently name created_nullifiers method across ProposedBatch, ProposedBlock and ProvenBlock.

[Mirko-von-Leipzig]

Non-PR question, but why does the protocol care about defining maximum counts? Feels like something that should be configurable - and while the node can enforce its own limits, this still sets the upper cap.

[PhilippGackstatter]

Yeah, good question. Some kind of ProtocolConfig would be better I guess. I guess right now it makes it easier to verify consistency, for example: The max number of inputs per batch and the max number of batches per block (1024 * 64 = 2^16) guarantees we can use a BlockNoteTree of depth 16 to represent all notes created in a block.

But we could verify such invariants in a ProtocolConfig::new constructor, and then miden-base could assume it is consistent.

[Mirko-von-Leipzig]

Might not be better :)

transactions
  .iter()
  .filter(|tx| tx.block_num != reference_block_header.block_num())
  .find_map(|tx| chain_mmr.contains_block(tx.block_num()).not().then_some(tx))
  .map_or(|tx| Err(ProposedBatcError:: ...)?;

[bobbinth]

Looks good! Thank you!

[PhilippGackstatter]

I pushed one more change related to this comment: 0xPolygonMiden/miden-node#709 (comment), which is to make BlockNoteIndex::new returns Option<Self> instead of panicking, so that users have control over the panic and it's more obvious that it panics since we have to unwrap or expect.