Investigate usage of the `remote` field for vault metadata optimisation

[joshuakarp]

Specification

VaultInternal currently has a remote boolean that indicates whether the vault has been cloned from some other node (i.e. it has an initial remote vault that it has been cloned from). This is also currently an indicator of whether a vault is immutable: cloned vaults are immutable. Previously, this information was stored solely in the metadata database, so any attempted commit to the vault would need to perform a database read to ensure that the vault was mutable.

There was previously some discussion on expanding this remote boolean to store some additional vault metadata for other optimisation purposes. We should keep this in mind for potential expansions to VaultInternal.

Additional context

• initial discussion of adding a remote field (and some other potential parameters for it): No longer preserve vault ID on cloneVault #253 (comment)
• comment from Scott about why the remote field is only a boolean now, and suggestions for how/when it could be expanded upon: Introducing vault sharing and the restrictions of pulling and cloning with vault permissions #266 (comment)

Tasks

1. ...
2. ...
3. ...

[CMCDragonkai]

Properties like this can be read from the DB once at the beginning and then cached as an in-memory property for the lifetime of the object.

This is mainly because this doesn't change. If it did change, managing cache coherency becomes a problem. So it's usually better to just leave it in the DB as an SoT and read from it each time when needed. For example see how we have to deal with node id changes.

However DB reads is not a significant cost here. First we make it work (correct), then we can make it fast(er).

[CMCDragonkai]

So I think majority (all?) of vault metadata should be kept in the DB for now and we can figure out how best to optimise later.