Boost Storage Scaling

To scale boost we need to scale both storage and retrieval. The retrieval scaling work is covered in the [Piece Directory milestone](https://github.com/filecoin-project/boost/milestone/14). This issue is to discuss scaling storage.

# Architectural Changes

### Configuration

Some configuration needs to be shared between boost nodes (eg the wallet used for publishing a deal). Ideally lotus would use the same config sharing mechanism, and probably booster-bitswap, booster-http etc

### UI

The UI needs to be updated to show aggregated information across all boost instances:
- Storage Deals page should show deals made with all boost instances and indicate which miner the deal was made with
- Deal Proposals page should show deals across all boost instances
- Sealing Pipeline should show information from all miners
- Deal Transfers page should show transfers across all boost instances

All of these pages should allow breaking out the information by boost instance and miner (where applicable).

### Boost process management

- It should be possible to add links between groups of Boost nodes and groups of miners.
Boost nodes would make deals with those miners in round-robin fashion
- When a boost node goes offline, other nodes should be able to take over its deals.

### Storage Provider execution

The Storage Provider is composed of several subsystems that need changes for scalability.

#### 1. Add miner ID parameter to APIs used by boost
- SectorsStatus(ctx context.Context, sid abi.SectorNumber, showOnChainInfo bool) (api.SectorInfo, error)
- AddPiece(ctx context.Context, size abi.UnpaddedPieceSize, r io.Reader, d api.PieceDealInfo) (abi.SectorNumber, abi.PaddedPieceSize, error)
- ComputeDataCid(ctx context.Context, pieceSize abi.UnpaddedPieceSize, pieceData storage.Data) (abi.PieceInfo, error)

#### 2. Fund Manager
The Fund Manager
- checks that the SP has enough funds to accept a deal
- "tags" funds for a deal when the deal is accepted
- releases the funds when the deal is published

We should move Fund Manager state and config into shared state between boost instances.
Note that the wallets themselves are on chain so they are already in shared state.

#### 3. Storage Manager:
The Storage Manager
- checks that the SP has enough available storage space to download a deal
- "tags" space for a deal when the deal is accepted
- releases the space when the deal is handed off to the sealing subsystem

The Storage Manager is specific to a boost node, so we may not need to change anything here.

#### 4. Deal Publisher
The Deal Publisher keeps track of deals that are queued for publish, and publishes them in a batch after the wait period expires (default 1 hour) or once the maximum number of deals per batch is reached (default 8).

To scale the Deal Publisher:
- Publish queue should be in shared state between boost nodes
- When timer expires:
- One boost node should pick up queued items
- Should mark items as processing
- Should write results to queue on complete
- There should be a fail-over mechanism if the node goes down

#### 5. Storage Ask
The storage ask (pricing) information should be moved to shared state.

# Open Questions

1. Should each boost node have its own libp2p address? Or should we use a load balancer?
2. How should boost processes be managed?
3. What configuration mechanisms do other filecoin implementations use?

# Related Issues
* https://github.com/filecoin-project/boost/issues/464