conex_verify_openssl performance

[hannesm]

is not great, compared to conex_verify_nocrypto. the reason seems to be that:
(a) each target file is read
(b) the content is passed to the crypto backend
(c) it is stored in a temporary file (/tmp/xxx)
(d) openssl sha256 is computed on the file

it would be faster (at least for the initial conex setup) to not read and write each target -- but keep in mind that incremental verification uses the diff provider, so there's not yet an on-disk representation of the target to hash. for a similar reason the signature verification cannot be optimised (these are embedded in conex, we need to verify them as detached signatures with openssl, that's why we need to write the to-be-signed part and the signature as individual files (plus the public key as another file)).

the not-reading-and-writing optimisation would likely speedup the initial verification, which is worth doing if it is measurable.