Refactor wallets table to separate actor and wallet roles

[parkan]

The current stable release of singularity treats wallets and actors as equivalent. This caused issues when offline wallet creation was added, because those wallets did not have ActorIDs (used as PK on the wallets table) until they hit the chain, which was resolved using a complex migration to change to SERIAL PKs and rebuild the join tables/FKs etc.

A more conceptually sound treament would be to re-position the current wallets table as actors (entities associated with a deal) and separate the private keys and related fields (i.e. credentials for signing) into a separate wallets type.

This has a number of advantages:

• clear separation of concerns
• makes the implementation of features like feat: Add standalone wallet tracking for deal monitoring without private keys #550 trivial
• allows using a secure keystore if desired, DB backups do not leak private keys if so
• sets us up nicely for integration with smart contract based dealmaking
• does not require brittle migrations of existing installs or pulling in new migration libraries

I would propose making this schema change first, then re-implementing the functionality in 2ba6325 on top

[parkan]

in my mind the path here is as follows:

• rename Wallet to Actor, remove PrivateKey in gorm (AutoMigrate does not drop the column)
• add new Wallet type/table for metadata related to signing functionality and a nullable Wallet.Actor relationship
• add an admin export-keys command: this will write all keys from the db to a lotus-compatible keystore, prompt the user to verify it, then do an explicit DropColumn on PrivateKey upon confirmation -- most likely this will work together with a warning on startup instructing users to export their keys if column is present and table is non-empty, much more lightweight than bolting on a versioned migration system
• Wallet.Actor relationships can be lazy populated in a getter (on chain message or funded wallet = actor exists)
• use standard signing libraries to load keys and sign

this will make adding back any desired wallet manipulation, non-owned actor tracking, and support for more secure key storage methods trivial and set us up for integration with smart contract based approaches

probably a ~day of work for the refactor, most of it spent on tests, code paths largely unchanged and no FK rebuilds necessary (WalletAttachment becomes ActorAttachment, keys looked up via join)