fix: avoid one in memory copy for unsealing

[dignifiedquire]

Refactors extraction to overwrite the provided data, rather than allocating another one.

[cryptonemo]

This is a memory visualization of a full 32GiB seal lifecycle test using the code from this PR, with unseal starting around 10pm.

For comparison, this is a partial memory visualization of a 32GiB seal lifecycle test on the master branch, with unseal starting around 1:28pm. Note that a large part of the test visualization at the start was unfortunately lost -- and that this run is not yet complete.

[cryptonemo]

To most directly take advantage of this, we also need the exposed unseal_range method in rust-filecoin-proofs-api to be re-factored in terms of get_unsealed_range.

https://github.com/filecoin-project/rust-filecoin-proofs-api/blob/master/src/seal.rs#L843

The unseal_range API call does not directly benefit from the memory reduction via mmap. It's possible that lotus does not use unseal_range in preference to get_unsealed_range, but it should be updated in any case since it can be done transparently to the API caller and the memory performance is strictly reduced.

EDIT: Still looking at the possibility on this. It may just be recommended that callers don't use unseal_range and it becomes a deprecated call. Anyone able to call it can alternatively call get_unsealed_range.

EDIT 2: It looks possible to leave the rust-filecoin-proofs-api repo alone and instead re-factor how unseal is called from the filecoin-ffi repo.

EDIT 3: Something like this should do it: filecoin-project/filecoin-ffi#162

[cryptonemo]

This is the latest run, with the updated/correct code. This uses the blst,gpu2 feature, so you can see that tree building is much more efficient in terms of time and memory. Unsealing starts around 4:41am

[cryptonemo]

And here is the latest run of master, comparable to the improved image above.

[dignifiedquire]

lgtm (can't approve my own PR)