Create diagrams for new processes implemented in vaults refactoring MR

[joshuakarp]

There are some residual diagramming requirements from the vaults refactoring MR.

All of these diagrams will also need to be integrated into some reference documentation for the entire vaults domain, based on the refactoring efforts.

Tasks

1. [ ] 1. iso-git exception handling for the cloneVault/pullVault functionality https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205#note_681727197 - may be a good idea to be done concurrently with the vault sharing testing
2. [x] 2. generalising the NodeConnection creation https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205#note_704400712 and the VaultMap (potentially may need something separate for the indexing operations for vault creation https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205#note_700844380 - see MatrixAI/Polykey#257)
3. [x] 3. vault lifecycle (state diagram - concurrently showing both in-memory state and EFS state) https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205#note_708692900
4. [x] 4. vault version allowable transitions https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205#note_692001869 current status here and further information in this thread https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205#note_697093105
5. [ ] 5. correct order of shutdown for resources (less specific to vaults refactoring - came up on the MR though: https://gitlab.com/MatrixAI/Engineering/Polykey/js-polykey/-/merge_requests/205#note_712570155) "some kind of diagram to show lifetime, or like a babushka doll"

[CMCDragonkai]

@pablo.padillo so this is an example of "reference" documentation, not tutorials, not theory, not how-to guides. And it is in fact a human written reference unlike auto-generated reference.