AMQP doesn't define an enum type itself yet the old implementation
listed our snum type as that in the schema despite what we are actually
doing which is serialising the enum down as a list of a string and an
int accompanied by a list of AMQP choices that represent all of the enum
values
Review Comments
Use fingerprinting of the enum types to catch whenever they're changed,
include the enum constants in the fingerprint to avoid any collisions
* Fix the ToStringSerializer so it interacts with reference counting correctly, and stop ref counting byte arrays since they are invariable wrapped in an object we do reference count.
* Pull out object reference condition into a helper function shared by serialization and deserialization
* Enable RPC start of Flows that return nothing (eg. Void).
* Fix blocking test (caused by not running mockNetwork).
Improve execution times by moving redundant setup() initialisation to only tests that use it.
* CORDA-540: Introduce mandatory reason for "kryoSpecific"
... before we forget why they are ignored in such a way
* CORDA-540: Write a test that exposes list serialization problem in AMQP mode
* Revert "Remove CompositeSignaturesWithKeys"
This reverts commit 9b3cad3
* Move CP_PROGRAM_ID into companion object
* Move COMMODITY_PROGRAM_ID into companion object
* Remove unused convenience function from FinanceTypes before we end up committing to maintaining it indefinitely.
* Move calculateDaysBetween into BusinessCalendar to eliminate FinanceTypesKt
* Rename KeyFactory to CompositeKeyFactory
* Move expandedCompositeKeys into TestDSL as the only place that uses it
* Move NullKeys out of their own package
* Move remaining crypto classes into superpackage
* Move utility classes out of crypto and into utilities package
Registration may fail due to low level serialization problems especially when running in AMQP mode
Also some minor improvements for exceptions reporting and test coverage
Rewrite ExchangeRate to use BigDecimal for the quantity multiplication, to ensure that there is no loss of precision during the conversion process. The previous version using double-precision floating point maths inherently means that the precision is not fixed, but is floating.
Change ExchangeRate to an abstract class rather than an interface, so the functions on it can be implemented directly rather than being extension functions, to improve Java compatibility.
Move `ContentSignerBuilder` into `net.corda.node.utilities` so it's not part of the API visible to CorDapp developers, when it's only needed inside the node itself.
