Incorporate subleveldown, transaction pattern, and serialize encrypt into all subdomains

[joshuakarp]

Currently our subdomains use a conglomerate of different variations of leveldb, encryption, and control of actions on the database. In the recently introduced ACL subdomain, the expected use of these has been implemented. We can use this as a framework for how we should structure the other subdomains.

• Incorporate subleveldown: usage of a top-level database for the entire subdomain, breaking down into lower levels for other database usages in that domain. For example, the gestalts subdomain previously used a prefixed key to specify separate levels in the database. This has recently been changed to also use subleveldown. The same should be done for all other subdomains. In the future, this could also potentially allow us to provide a single leveldb for all domains, and simply separate the subdomains (gestalts, nodes, etc etc) into separate subleveldowns. This would allow us to perform cross-domain transactions and atomic operations.
• Transaction pattern: see ACL source
• Serialize encrypt: see ACL source (@CMCDragonkai can also comment on these latter 2)

---

Domains to be refactored:

• IdentitiesManager - @joshuakarp
• SessionManager - @DrFacepalm
• Sigchain (+ change sequence number key to use lexicographic integers) - @joshuakarp

[CMCDragonkai]

In client refactoring this is done for DB, ACL, GG.

We are going to apply it to notifications and VM as well.

And any others. The only one that isn't is the key manager which will require its own database.

[CMCDragonkai]

I believe this is done for nodes domain as well. And @scottmmorris has done this for the vaults domain.

Still to do:

• IdentitiesManager - for tokens
• SessionManager

There's also the keys domain which currently the DB depends on, I have a plan for making KeyManager also use DB, but that means DB is managing the DB key outside of leveldb.

[joshuakarp]

Added these domains as todos in the top-level description.

[joshuakarp]

Sigchain also needs to be refactored too (+ changing the sequence number key to use lexicographic integers)

[CMCDragonkai]

@joshuakarp did you do it for the IdentitiesManager?

BTW in the future this issue should be a Development spec, and then the checklist is actually in the PR/MR.

[joshuakarp]

@CMCDragonkai I haven't had a chance yet.

Re the checklist, didn't we say last meeting that issues should always have a task list? i.e. every issue template has a checklist

Unless its a Design issue, where tasks may not be elicited quite yet, I feel that issues should always have a task list.

[CMCDragonkai]

Yea so development issues can have a checklist as well the PRs fixing them. But sometimes you need to write a task list that is copied to the PR and so therefore the checklist is on the PR not on the issue.

So I'm differentiating the checklist from tasklists. Checklists have checkboxes.

[CMCDragonkai]

@DrFacepalm I think he has done it for SessionManager.

[joshuakarp]

Ah gotcha - I didn't realise the distinction between checklist and tasklist. That makes sense.