Performs the following renamings in the vetKD API in accordance with the
[latest
changes](dfinity/portal@add1c71)
in the [spec PR](dfinity/portal#3763):
* `derivation_id` --> `input`
* The name `derivation_id` often caused confusion and `input` is a more
standard name in the context of key derivation schemes.
* `derivation_domain`
([previously](#4049)
`derivation_path`) --> `context`
* The main use case for the derivation domain/path is to do domain
separation, i.e., to specify the context in which the derived keys are
to be used. Given this, directly calling it context seems beneficial in
that it makes the meaning of the field more clear and intuitive, and
thus the API easier to use.
* `vetkd_derive_encrypted_key` --> `vetkd_derive_key`
* Although the fact that the returned key is encrypted is relevant in
that it ensures that nodes cannot see the key in clear text, this can be
considered an implementation detail. Also, the name
`vetkd_derive_encrypted_key` is somewhat long. In any case, in the
returned struct the (single) field is still called `encrypted_key`, so
it is still explicit that the returned key is encrypted.
* `encryption_public_key` --> `transport_public_key`
* Everyone everywhere (in publications, slides, demos, etc.) called this
"transport public key". The reason this was not called
transport_public_key in the API so far was because the containing API
method was called `vetkd_derive_encrypted_key` and the name
`encryption_public_key` should have made it clear that it is this very
public key under which the _encrypted key_ is encrypted. Now that we are
removing the part `encrypted_` from the API name, this reason is
obsolete and we are free to call it `transport_public_key`.