test(crypto): CRP-2949 add system test for ingress expiry validation

[fspreiss]

Extends the rs/tests/crypto/ingress_verification_test.rs system test to ensure that updates, queries, and read state requests fail if the ingress expiry is in the past or too far in the future. This is done for all the different API versions.

Also extends the testing infrastructure to better support read state requests. In particular, moves the sign_read_state function from util/delegation.rs to util.rs, because there are already the related sign_query and sign_update.

[randombit]

This looks good to me, thanks.

I did notice you took a different approach with testing the various API versions, namely iterating over the supported versions in a loop within a single test rather than creating multiple system test instances to test the different APIs. For the delegation tests it seemed like doing it the latter way was faster (at least on my devenv), wasn't sure if you tried this and it didn't work out, or just preferred your approach.

I don't think it matters much either way, just wanted to point it out. Fine with me to merge this as is.

[fspreiss]

@randombit, as discussed in the team meeting, the main reason I took a different approach is that update calls have API versions 2, 3, and 4 (2 being the old asynchronous one, 3 and 4 being the new synchronous one, where 3 is already deprecated), while queries and read_state requests currently have version 2 and 3 (but no version 4).

What we could do is

.add_test(systest!(query_with_invalid_expiry, 2)),
.add_test(systest!(query_with_invalid_expiry, 3)),
.add_test(systest!(update_with_invalid_expiry, 2)),
.add_test(systest!(update_with_invalid_expiry, 3)),
.add_test(systest!(update_with_invalid_expiry, 4)),
.add_test(systest!(read_state_with_invalid_expiry, 2)),
.add_test(systest!(read_state_with_invalid_expiry, 3)),

but ideally we would automatically iterate over all supported API versions based on some API-version enum (e.g., the ones used here could be cleaned up/extended accordingly), and it seems this iteration over the enum variants is best done within a test, although this has the downside that the tests would run sequentially rather than in parallel.

For now, I'll just merge this PR to make progress towards the test parity with Haskell, but I'm happy to refactor later (e.g., according to the above-sketched approach).