Integrate gestalt graph with ACL

[joshuakarp]

Two comments:

@CMCDragonkai : https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/188#note_589103130

Functions that will require changes:

1. setIdentity - nothing happens
2. unsetIdentity - removal of an identity should result in removing it from the trust database
3. setNode - nothing happens
4. unsetNode - removal of a node should result in removing it from the node database
5. linkNodeAndIdentity - conditionally set in the trust, if linked node/identity already trusted
6. unlinkNodeAndIdentity - ?
7. linkNodeAndNode - conditionally set in the trust, linked node already trusted
8. unlinkNodeAndNode - ?

I realised that I haven't even got tests for the unlinking operations in GestaltGraph. Furthermore, I'm not sure what unlinking means here. If I add a new node/identity and link to an existing node/identity, I form a gestalt between them. If they are now unlinked, then they are no longer part of the same gestalt, but they may form their own gestalt now. If they form their own gestalt, and the previous gestalt was trusted, does this mean that both splits are still trusted?

If both splits are trusted, and a trusted gestalt links up with another gestalt, does this other gestalt becomes trusted as well?

I guess trust can be greedy or lazy. If greedy, just because a gestalt is split doesn't mean any of them lose trust. And when 2 gestalts join, and one is trusted, the result is also trusted.

If a split gestalt were to lose trust, what would this mean? Which split would lose gestalt? You don't really know. It's only possible to explicitly revoke trust for a given gestalt, but this has to be a user action.

Therefore splits retain trust at this point, it is possible however to make the other system less trusted later.

Therefore:

6. unlinkNodeAndIdentity - nothing changes
7. unlinkNodeAndNode - nothing changes

@CMCDragonkai : https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/188#note_601518284

Ok here is the uses:

getNodePerm
getVaultPerms - this will GC invalid node ids

setVaultAction - works for new vault ids, and only existing node ids
unsetVaultAction - this removes the action, works if the vault doesn't exist, if the node id doesn't exist or doesn't have the action

setNodesPerm - this errors out if any node id already exists, only for non-existing node ids, basically totally new gestalts
setNodePerm - can be used for a new gestalt, or if pointing to an existing gestalt, it will update the gestalt's perms

joinNodePerm - use this to join new nodes to a pre-existing gestalt
joinVaultPerms

unsetNodePerm - equivalent to deleting a node id, it does not delete the perm unless the ref count goes to 0, it may result in vaults having invalid node ids
unsetVaultPerms - deletes the vault, but does not touch the nodes

When calling setVaultAction, the caller must be using the node id that already exists in the ACL. If the node id doesn't exist in the ACL, an error is thrown. However that node ID should also represent a gestalt. Every node id pointed to by a vault needs to be an independent gestalt.

If the caller wanted to set a vault action for an existing gestalt, and that existing gestalt already exists in the vault nodeids, then how can the caller be sure to pick the right node id to avoid putting duplicate node ids into the vault permissions?

It would require one of 2 solutions:

1. That the ACL can have access to the GG to check if it there is a gestalt-equivalent node id
2. That the ACL is not directly accessed, it's wrapped by the GG or by some composition that can ensure that it checks with the right nodeid first.

Because there's no canonical node id for any gestalt. There's no efficient way to do the former. Checking will be expensive cause you have to iterate over the node ids

The latter solution is more likely to work... requires some thinking.

[CMCDragonkai]

Done now in client-refactoring. Client-refactoring will be the last MR on Gitlab, the rest will go to GitHub.