change behavior of recover_key to better support variable length keys

[b1bart]

Change Description

#7421 introduced support for WebAuthN keys in the recover_keys intrinsic. As both keys and signatures for WebAuthN are not fixed length actually using this intrinsic was difficult owing to the semantics where:

• passing too small of an output buffer would assert, failing the transaction
• there was no input that would return the required output size without risking assertion

This change attempts to modify the semantics in a way that is most backwards compatible with the existing semantics.

For the K1 and R1 suites the semantics are the same.

For WebAuthN, the semantics are:

• output buffer sizes from [0..33) will assert (maintaining old semantics where those values would always assert)
• output buffer sizes from [33..+inf) will write as much of the recovered key data as will fit in the output buffer and return the total available key data size as the return value.

This allows contract developers to have a reasonable buffer size for a single-call use case and fall back to allocating a larger, correctly sized, buffer if and only if that fails.

Outstanding work

• Unit tests for the behavior which depends on EOSIO.CDT integration of the variable length key/signature types. turns out this was implementable without requiring CDT changes.

Consensus Changes

• Consensus Changes

API Changes

• API Changes

Documentation Additions

• Documentation Additions

[b1bart]

I ended up re-enabling and fixing the rest of the api tests for the crypto api. Mostly this reverted it back to a pre eosiolib-wrapper form which I think is more appropriate for testing the intrinsic ABI as it removes obfuscating elements.

[arhag]

There doesn't seem to be a need for this comment. (Same goes for the other two similar comments above. In fact, the one called "Error Here" is misleading because it is directly above a call to an action that is supposed to, and does in fact, succeed.)