Add utility functions for requesting transaction keys and a small example flow which uses
these functions for testing purposes. These keys are required in for the anonymisation of
transactions, by providing per-transaction keys which cannot be associated with the owning
party's keys without an intermediary certificate.
* CORDA-305: Refactor CordaRPCClient into :client:rpc module
* CORDA-305: Remove the Kotlin test framework from the artifacts.
* CORDA-305: Migrate serialisation whitelist into node-api module.
* CORDA-305: Clean up unused RPC observables.
* CORDA-305: Add :client:rpc module to documentation tasks.
* CORDA-305: Include :finance into :client:rpc for its serialisable classes.
* CORDA-305: Move test classes into the correct directory.
* CORDA-305: Migrate :finance dependency from :client:rpc into DemoBench.
* CORDA-305: Update wording of TODO about handling Observables.
* We were leaving trailing attachmentStorage on pooled kryo instances after some tests. Changed attachment storage logic to make it impossible to leave it behind.
* Some low level tests corrupt the Kryo config, so do not return to pool when this is the case. Also, we discovered that Kryo is caching class name to class resolution. We don't want to do this where attachments are involved. The errors raised highlighted a class missing from the whitelist. Need to write a unit test to test the class loader issue.
* Unit test for attachment class loading with kryo.
Convert NodeVaultService states to return Iterable (backed by Sequence) Vs the old way using a List. Worth noting this relieves memory pressure as the number of vault states grows.
* remove toList in ContractUpgradeFlowTest
Basic crypto API to support 5 signature schemes and MetaData-ed signatures.
Supported schemes: (1) RSA_SHA256, (2) ECDSA_SECP256K1_SHA256, (3) ECDSA_SECP256R1_SHA256, (4) EDDSA_ED25519_SHA512, (5) SPHINCS-256_SHA512.
To sign a transaction, a signer should create a MetaData wrapper that contains transaction's merkle root and some extra information, such as signer's public key, timestamp and visibleInputs. Actually, MetaData is utilised to support a practical partial, blind and extra-data attached signature model.
When a MetaData object is signed, the signer sends a TransactionSignature object that contains the signed output and the corresponding MetaData object.
Remarks:
This is an temporary solution for signature algorithmic agility. Further development is required for a robust and extensible Crypto Manager/Provider PKI that will support certificate creation, key generation, signing/verifying, deterministic key derivation, encoding formats, SGX/HSM support, identity and key management, versioning, revocation, asynchronicity, metadata, partial sig. policies etc.
* BFT notary prototype: add a non-validating service.
Each replica now validates the transaction timestamp and returns an individual signature to the BFT client. The client then returns a list of signatures back to the notary service flow.
The validating variant is still incomplete - it requires the ability to suspend flows on arbitrary function calls.
* Exclude old version of Javassist in favour of Hibernate's version.
* Comment why we are excluding javassist:javassist, and add TODO for when junit-quickcheck 0.8 is released.
Make notary flow return a collection of signatures to support the BFT notary. For a single-node or RAFT notary it would just contain a single signature.
