Investigate test failure related to Namespace table.

[philippecamacho]

Commenting out the tests related to #746, triggers a test failure.

Also remove the comments related to #746.

[philippecamacho]

So when using the test case: vec![vec![], vec![7, 9, 11], vec![10, 5, 8]] the test fails this assert:
assert_eq!(block.num_namespaces(&actual_ns_table), derived_nss.len());
The left member returns 2, while the right member returns 3.

The reason is that the block and the namespace table are reconstructed from the transactions: given that the first namespace is empty, it has no transaction attached to it and thus the number of namespaces in the block is only 2 and not 3.

cc @ggutoski @akonring

I wonder if it is worth handling empty namespaces... Why would someone include an empty namespace inside a block? Does it not open the door for DoS attacks as one cannot charge a fee for an empty namespace?

[ggutoski]

Ah yes, I remember now! I should have posted a code comment. 🤦

The from_transactions constructor always produces a "valid" / "well-formed" block. Such a block will never have an empty namespace. So our basic_correctness test should not include empty namespaces.

A "malformed" block composed of arbitrary bytes might have empty namespaces, so that test should support empty namespaces. But that's the scope of #785 .

For this issue, I think it suffices to add a code comment explaining that from_transactions will never produce an empty namespace, and then delete those tests from basic_correctness that include an empty namespace. It's a trivial fix, so if desired we don't need a separate PR---we could instead bundle it into another nontrivial PR.

[philippecamacho]

Ok I will add the comment in the in the PR for #1010.