Distinguish between partial (or foreign) and full (or native) account

[igamigo]

For "read-only" (foreign) accounts, I think there are 2 main ways in which they can be used in a client:

• Requesting a subset of a snapshot (for blocks near the chain tip) of its data from the network with get_account_proof. I question the value of keeping this data in the store because it seems like it's mostly an ad-hoc thing. Feels like it's better suited for an in-memory cache that the DataStore can reference and then forget about, maybe even throughout more than one transaction (this is the way it is implemented for now, since at first we didn't have full support for PartialAccount from the store). But maybe this is not fully correct and there are some better use cases that derive from keeping this data in the store (consistency and a centralized source of truth is nice enough, but not as much if it makes the Store interface and overall logic sensibly more complex).
• Importing externally-owned accounts that get synced periodically. I think this will work if we just make very few and minor adjustments: right now we can import accounts and then on syncs, their state gets fully updated. This naturally extends well with the new syncing model where you import the whole account once (by syncing it completely to the client's sync height), and then you periodically get only the new values for maps and assets.

I think mostly the lines between owned accounts and foreign accounts are fuzzy in a way because whether you can execute transactions with them depends on two things AFAICT: whether you can retrieve a PartialAccount that contains the right subset of data (ie, for any state that you want to update from it) and whether you can run the account's auth procedure (which in most cases reduces to whether your TransactionAuthenticator can provide the correct signature).

Regardless of how we want to store and manage accounts (both owned and external), the pruning story will be very important because there's no need to keep around most of the data that will be derived from managing account states. For reference, at block ~150.000, the 0.12 (current) faucet's store was around 1GB with 93K account states/transactions and ~100K output notes. Because all the historical data is kept right now, it grows larger than it needs to, quicker. We have #1158 for at least part of this which was not added to this milestone but I think we might want to prioritize it soon.

All of this also ties a bit into what a TransactionRequest describes and how the overall execution flow happens: when you look up potentially ephemeral FPI data from either an in-memory structure, the Store, or even the network, etc.

Originally posted by @igamigo in #1563

We need to design a way in which we can leverage the account endpoints (for syncing account proofs, storage maps and vaults) for downloading the minimum amount of data at any point.
We also need to decide whether we want to keep partial data around (for example, from foreign accounts) and how we could manage this. There is some more context in the referenced issue.