Don't send cancellation after success

[iinuwa]

With the changes in #204, we need to follow up not to send the cancellation event if the cancellation occurs after.

One quick fix I can think of is to stop emitting events from the BackgroundEvent stream (or the individual streams it is composed of) returned by start_discovery(), e.g. by checking that the cancellation is not cancelled before emitting a new state. I think this is safe, since we never depend on Cancelled showing up in the BackgroundEvent stream:

• If the caller cancels, the FlowControlService will receive that and pass it down to CredentialService, so it doesn't need to be passed back up.
• If the user cancels, that will be received in FlowControlService, which will cancel CredentialService. We can either have CredentialService emit a "Cancelled" error, or we can just ignore whatever it says and return a cancelled error directly from FlowControlService
• If the credential service cancels a transport after success, we can ignore the output
• If credential service reports an error, we'll wait for FlowControlService to send a cancellation. If FlowControlService dies, then the sender side of the channel will close, and CredentialService can clean itself up.