Make set_contract_storage fallible

[xermicus]

Related issue #1682

This is a very naive approach to the problem: If set_contract_storage can fail because the data does no longer fit into the encoding buffer, contract authors can account for that possibility. I don't think we need this for decoding because I don't see how something would fit in the buffer while encoding but no longer while decoding it.

A less invasive way would be to just add a try_set method to Lazy, but I thought this might be useful to have generally available. We also could introduce try_set_contract_storage into the API instead so we don't break the existing API. WDYT? Was there was an explicit reason set_contract_storage does not return a Result?

This is an early WIP. Todo:

• Don't use Error::Unknown, might need a new one
• Adapt integration tests
• In the dispatch it just unwraps the result, however now that we have a Result we could as well do something about it other than panic
• Implement tests
• Probably many more

[xermicus]

@ascjones @SkymanOne WDYT?

[SkymanOne]

I don't think we need this for decoding because I don't see how something would fit in the buffer while encoding but no longer while decoding it.

with #1869 it is now possible for a contract to encode data using a larger buffer size, and then replace its code hash with a smaller buffer size and then fail. This can also pop up during cross-contract execution. So we need the same check for decoding.

[SkymanOne]

size_estimate perhaps is a better name?

[SkymanOne]

Look like a good start I would personally add try_set_contract_storage() to avoid breaking changes and be as close to Rust interface (e.g. from() and try_from()) as possible.

I would also like to hear more how this work would lead to the implementation of StorageVec as you mentioned it as a related issue.

[xermicus]

Thanks @SkymanOne for your comments, good points. I'll pick it up again.

[xermicus]

I would also like to hear more how this work would lead to the implementation of StorageVec as you mentioned it as a related issue.

Ah, so the problem this PR solves is more that currently there is no way to probe whether setting the storage will fail because of the encoded data size,

[xermicus]

Closing in favor of #1910