accounts: fix two races in the account manager

[karalabe]

The first commit in the PR fixes an init/run data race in the account.Manager: Listing the wallets from a backend has the side effect that a filesystem scan will be run and anything new will fire a wallet event. The wallet event is forwarded to anyone subscribed.

The issue was that the account.Manager first subscribed to wallet events, then did an account listing, and only afterwards fired up the goroutine to consume the subscriptions. If the keystore contained more than 8 accounts, the wallet listing actually fired 8+ events, overflowing the manager's subscription and blocking. But since the manager itself is firing the events internally from the listing, it cannot consume them, locking itself up.

The issue is simple enough to correct, do the initial scan of the wallets first, and only afterwards subscribe to events. Note, this might in rare cases cause an account not to be detected (if it's created after the manager lists the accounts and before it gets to the subscriptions). But that should be picked up at the next fs scan some seconds later, so it's not that bad.

---

The second commit moves the keystore.fileCache to its own file to keep the account_cache.go file a bit shorter and cleaner. Apart from minor polishes the commit also fixes a data race in the directory scanning: currently the scan itself can run concurrently, and only saving the results is done in sync. This is not correct, because "gathering" the results depends already on the previous state (notably the modification time). Two concurrent scans results in the same files being gathered as new, the first obtaining the lock reports them as new, the second reports them as modified. The result is that all accounts get added, deleted and readded to the keystore account cache for every concurrent scan.

The solution here is to just make the folder metadata scan lock the entire file cache. The lock is held for 50ms anyway, so it's not a heavy congestion, and can make the code cleaner and simpler to reason about.

[holiman]

LGTM