Feat/retrieval market #1552

[shannonwells]

Closes #1552

Support non-blocking creation of payment channel and adding funds via implementing the new go-fil-markets API, namely:

• GetOrCreatePaymentChannel now should

  1. If the payment channel doesn't exist:
     1. initiate payment channel creation and return address.Undef + message CID to wait for
     2. Allow a retrieval client to wait for this message CID and receive the new payment channel address when complete
  2. Otherwise add the value provided to the existing payment channel

• New API methods: WaitForPaymentChannelCreation, WaitForPaymentChannelAddFunds

[hannahhoward]

So,
There are unfortunately a few problems here, and this turns out to be quite a bit more complicated than I'd imagined.

The problem here is that the payment channel manager is stateful, and intended to be used by multiple consumers, in different threads. That's why there's a mutex lock around GetPayCh in the payment channel manager.

So there are a couple problems this raises:

1. First, behavior that was enclosed by the mutex is not now (your WaitFor methods)
2. There's a much more serious problem though -- the entire architecture of GetPayCh relies on it being an atomic operation (including the wait) -- that's the origin of the TODO comment about waiting outside the store lock. The fact that you have it separated into independent methods raises various issues -- you're relying on the caller to call WaitFor -- what if they don't? Based on the fact that the manager is stateful, you still need to wait for the message and update the channel state somehow.

So, this starts to look like a more significant rearchitect. Probably I would propose something like this:
In the initial methods, get to the end, then kick off a go routine to wait for the message internally, save the results and release the mutex only when finished (so the contents of the WaitFor methods live in the go routine)
I would then remove the WaitFor methods on the PayCh manager.
Instead, in the retrieval adapter itself, I would just call StateWaitMessage directly, and in the case of create, read the returned address directly.

[hannahhoward]

LGTM by me.

@magik6k we still weren't totally sure what to do about the locking mechanism here, so for the time being we've left it at basically replicating what was there before.

Btw, we're trying to have the markets modules block as little as possible on chain operations, so that we can get to the point of being able to resume in progress market transactions when a node shuts down and restarts. In this case, on a restarted retrieval deal, we do not want to add funds / create the channel again in the case where the message was already submitted.

[magik6k]

1 comment, then LGTM