Verify that we don't panic inside of MT library

[cryptonemo]

@schomatis suggested we keep this in mind going forward.

[storojs72]

The question "How to guarantee that code will never panic?" is rather broad and looks like it doesn't have straightforward answer. There is a discussion where it is proposed to make usage of crates like no-panic and panic-never while development libraries for embedded platforms as a standard. The idea of those crates - to statically analyse branches of final program and fail the compilation with a linker error that identifies the function name that may panic. This approach can be used for more or less logically simple libraries (software in embedded systems) but most likely it will not work in our libraries like this merkletree library and higher-level libraries in the Proofs stack of Filecoin due to their complexity. So, I think, the best what we can do is to analyse most probable cases when library can panic and try exploit them. Ultimately it will result to introduction of negative tests if mentioned cases will be found.

From my point of view, most probable cases of panic can be found while Merkle Tree instantiation, when "bad" data is provided (problems with stores) and current input validation rules can't detect this and when inclusion proof is computed / validated. Other functions like root, len, row_count, leaves are currently implemented as getters and will not panic guaranteed. So, I would focus on tree instantiation and generating / validating Merkle proofs when:

• wrong/non-existing filepath is used in StoreConfig;
• store file has been removed, while instance still relies on it;
• store file has been modified;
• store file has wrong permissions.