maintain a dependency graph for the namespace delegations

namespace delegations are a bit tricky as there can be an arbitrary number of delegations before we reach the actual key that will be used for authorizations. think of it as a certificate chain where we get a series of certificates and we need to figure out a path from one certificate to the root certificate.

NOTE: this class is not thread-safe

properties of the graph:

• the nodes are the target key fingerprints
• the node with fingerprint of the namespace is the root node
• the edges between the nodes are the authorizations where key A authorizes key B to act on the namespace in this case, the authorization is outgoing from A and incoming to B.
• the graph SHOULD be directed acyclic graph, but we MIGHT have cycles (i.e. key A authorizing B, B authorizing A). we don't need to make a fuss about cycles in the graph. we just ignore / report them assuming it was an admin mistake, but we don't get confused.
• root certificates are edges pointing to the node itself. they are separate such that they don't show up in the list of incoming / outgoing.
• we track for each node the set of outgoing edges and incoming edges. an outgoing edge is a delegation where the source node is authorizing a target node. obviously every outgoing edge is also an incoming edge.

computation task:

• once we've modified the graph, we compute the nodes that are somehow connected to the root node.

purpose:

• once we know which target keys are actually authorized to act on this particular namespace, we can then use this information to find out which resulting mapping is properly authorized and which one not.

authorization checks:

• when adding "single transactions", we do check that the transaction is properly authorized. otherwise we "ignore" it (returning false). this is used during processing.
• when adding "batch transactions", we don't check that all of them are properly authorized, as we do allow temporarily "nodes" to be unauthorized (so that errors can be fixed by adding a replacement certificate)
• when removing transactions, we do check that the authorizing key is authorized. but note that the authorizing key of an edge REMOVAL doesn't need to match the key used to authorized the ADD.