Document the included samples in the docs again so there's some continuity from v1 docs, while making it clear they're not best practice examples but instead illustrate solutions to various use-cases.
Previously when de-anonymising a Party instance, the name of the Party was used rather than
the key, meaning a Party could be constructed with a random nonsense key and any name, and be treated as corresponding to the well known identity. This is not a security hole in itself as
in any real scenario a party shouldn't be trusted without having been registered, it creates
a significant risk of a security hole depending on how trusted the anonymous identity is, and
the returned identity is considered.
The motivation for this came with the recent change that a default notary is started by the driver, which if ignored will leak the notary process.
Also, waitForAllNodesToFinish() has been replaced by a driver parameter.
* Network map cache using Network map client instead of artemis. -- WIP
* fix up after rebase
* address PR issues, split network map update test, added todos to remove sleeps
* move jimfs and baseDir to field variable
Most uses where with MockNetwork which recently got a defaultNotaryIdentity property for dealing with the default single notary case. The remaining uses where in flows.
network-parameters file read in by the node at startup, of which only the list of notaries is used. For now, the driver and MockNetwork have been updated to require notaries to be started first. This is so that the same set of network parameters can be defined for all the nodes.
CN in the legal name is not longer disallowed since it's no longer reserved for distributed notary names.
Single-node notaries now only have one identity, their main identity. Nodes part of a cluster continue to have two.
(Based off Kasia's work)
* [CORDA-446] Clean up other mentions of network map node and logic
* Rename AbstractNetworkMapService to NetworkMapService and remove the empty NetworkMapService
* fix build
* fix artemismessaging tests
* pr comments
approach which assumes a dedicated node for observers: states that are
reported to the node will appear in the database and update feeds as
normal. Apps that expect all updates to be relevant to themselves may
need adjusting if they run on an observer node too, but this is likely
to be rare.
