Add more positive & negative E2E tests for identity (multiparty mode and non-multiparty mode)

[awrichar]

The E2E identity tests are currently a bit thin. As a very central piece of FireFly's architecture and security model, they really should have more positive tests, and particularly some negative tests to verify disallowed operations.

Background on identities:

• Identities in FireFly are senders and receivers of data
• They are of type "org", "node", or "custom"
• They are described with a DID
• Org and custom identities are on-chain identifiers with attached blockchain keys; node identities are off-chain identifiers with an attached dataexchange ID
• Orgs may have children of any type, custom identities may only have custom identity children, nodes may not have children
• Each FireFly instance that participates in a multi-party system must have a root "org" identity with at least one "node" identity child
• When sending an on+off-chain message (private or broadcast), you can choose your on-chain (org or custom) and off-chain (node) identity
• When receiving an on+off-chain message, the node identity must be a child of the on-chain identity or one of that identity's ancestors, and both pieces must be signed appropriately by those identities
• Slight aside: the "node" terminology is overloaded, as we sometimes also refer to FireFly itself as a "node" - but that is now somewhat distinct from the special "node identity" established between FireFly and dataexchange

What we test today:

• The multiparty on+off-chain messaging suite thoroughly uses the baseline identity functionality across two FireFly members - ie 1 root org with 1 node each
• The multiparty identity suite creates "custom" child identities to the root org, and uses those child identities to send basic broadcast and private messages

Gateway mode suite:
We need a copy of this suite added to the "gateway mode" (ie non-multiparty) runners. This group of tests uses a single node in isolation, which creates local definitions but does not share them with any other nodes. We need (at minimum) a basic test that creates org and child identities and then queries them back.
Note: to run the gateway suite you must run make MULTIPARTY_ENABLED=false e2e

Additional tests that could be added to the existing multiparty identity suite:

• Registering invalid identities (keys that have already been used, parent/child relationships that are not allowed, trying to register a child of someone else's org)
• Sending to invalid recipients (ie send a private message to an org+node that exist but are not actually related)
• Deeper nested identities

Negative tests should usually result in an event of type message_rejected. Most tests are not currently listening for this event (usually just message_confirmed), so the websocket listeners would have to be expanded to listen for this.

[awrichar]

Partially blocked by #952

[annamcallister]

I've done a very small part of this issue under #996.

Some observations from some initial attempts at some of the other negative test cases

• parent/child relationships that are not allowed - this results in a 400 error response to the API call registering the identity rather than a message_rejected event
• trying to register a child of someone else's org - I was able to successfully register an identity as a child of org 1 using the org 2 client. I don't know whether this was due to me writing code that didn't do what I thought it did, whether I've misunderstood the test case, or whether there is actually an issue here.

[awrichar]

The second bullet is interesting - it might be due to the way the CLI sets up the blockchain identities. Bottom line is if you don't have access to org 1's private key, you should not be able to create a child of it. But in the local environment, everyone might have access to all the blockchain keys...