There are a variety of pathological circumstances in which the
client can be unaware of orders that the server claims are active
(in epoch or booked status on the server). These include using
an old or corrupt DB file that lacks current orders, errors saving
submitted orders, and such trades having been self-revoked such
as if the server were down past the taker's locktime. Each of these
scenarios has been encountered in the wild.

This change introduces a simple "blind cancel" mechanism for submitting
cancel orders for any of the orders reported by the server on connect
that are not presently "active" according to the client. In submitting
these cancels, no accompanying tracked trade is present, only an entry
in the new blindCancels map. This map facilitates handling of the
preimage request for the order (if is accepted), as well as silencing
errors that would occur in the match/nomatch handlers.

Future work should introduce a method for manually self-revoking orders
while the DEX connection is down. Presently, this code will only be
used for the anomolous cases described above.

This fixes a bug where a revoke_order notification from the server that
refers to a cancel order ID would cause the client to revoke the
targeted trade order instead.

Most of the time a cancel order is declared stale and deleted after it
becomes 2 epochs old, a heuristic we use to infer when we've missed the
preimage request for the cancel order.  This was necessary since unlike
trade orders, we don't expect to get status of cancel orders.  However,
we neglected the possibility that we could miss the preimage request
but reconnect in time to receive the revoke_order notification at the
end of the epoch collection period.

When handleRevokeOrderMsg detects that the order ID is a cancel order,
we now unlink the cancel order and send a TopicFailedCancel order ntfn.
The TopicFailedCancel topic previously was only used when cancel orders
were declared "stale", meaning they were more than 2 epochs old.