A PK context currently has the following fields:

• pk_info (legacy, on its way out but we're not there yet)
• psa_type
• priv_id
• pub_raw, pub_raw_len
• bits
• ec_family (if EC enabled)

The theory/goal is that once a context is populated, by using one of the 5 public APIs that populate contexts (wrap PSA, copy (public) from PSA, parse (public)), then all those fields (except currently priv_id for public keys) have non-zero values that are consistent which each other.

This is not directly tested so far. It's only indirectly tested by ensuring that the functions that operate on a PK context work with each of the 5 possible ways of populating the context. However that's not a good strategy: for example parsing has several code paths, and it was recently discovered that one of them was not populating pub_raw as it should. It would be impractical to require that each function that operates on a PK context be tested not just with all of the 5 methods of populating, but also exercise all the cases for each method (parsing PEM vs DER etc).

Instead we want to have a central test helper function that validates all the invariants that a populated PK context should satisfy, and then call that helper in each of the existing test functions for parsing (and other methods of populating a context - won't repeat that part). Assuming we already had test data exercising each code path of parsing, this will ensure that parsing always correctly populates all the fields of the context. Then functions that operate on a PK context can just rely on it and never get bad surprises.

Note: ec_family is actually redundant and can be extracted from psa_type. Removing that redundancy is out of scope for this task - edit: see #10583