improve the subscription life cycle event and add new settings

[hgiasac]

Fix #80
The PR improves the subscription client with a new event and settings

Event

// OnSubscriptionComplete event is triggered when the subscription receives 
// a terminated message from the server
client.OnSubscriptionComplete(fn func(sub Subscription))

Settings

client.
    // the client should exit when all subscriptions were closed, default true
    WithExitWhenNoSubscription(false).
    // WithRetryStatusCodes allow retry the subscription connection when receiving one of these codes
    // the input parameter can be number string or range, e.g 4000-5000 
    WithRetryStatusCodes([]string{"4000", "4000-4050"})

[hgiasac]

@sermojohn this improvement is for the subscription run flow that you suggested. There is no recursive Run call in goroutines. All events are centralized in the main loop to control the retry behavior.

[sermojohn]

What is the difference between id and the key, so to have both per subscription?

[sermojohn]

Oh, I see but looking up the subscription either by the key or the id seems complicating, no?

[hgiasac]

We can separate them into 2 functions. However, I just unify the search function into a single function. We still need to find the subscription by id internally but the user only has the original id before resetting.

[sermojohn]

@sermojohn this improvement is for the subscription run flow that you suggested. There is no recursive Run call in goroutines. All events are centralized in the main loop to control the retry behavior.

Nice improvement!

I ran our test-suite, but having some issue. This could be due to the synchronisation, I need to check further.

How should the library handle Subscribe calls happening during or after close is called?
In my test, here is the error I get:

failed to write JSON message: failed to get writer: WebSocket closed: read timed out: context canceled

[hgiasac]

I assume that the client should wait until the cleanup process is done. Anyway, I'll fix this

[sermojohn]

Thanks!
Taken that we do not lock, there are still chances that Subscribe will be triggered on a closed connection.
But this seems correct to me, based on existing logic.

[hgiasac]

I haven't found any absolute approach to solve this race condition issue. However, the chance is low except the user tries to close and run repeatedly in parallel. IMO it's better to create a new client and subscribe because all subscriptions were cleared after the client was closed. There isn't any benefit over the new client.