Configurable concurrency level for messages processing

[maruqu]

This PR adds max_cb_concurrency parameter to subscribe method. Concurrent cb execution limit is achieved using asyncio.Semaphore.

TO DISCUSS:

• [x] What should be a default max concurrency parameter
• [x] Should we deprecate is_async parameter (seems redundant and a bit misleading now)

Resolves #119

[wallyqs]

Thanks for the contribution! About the discussion points you mention:

What should be a default max concurrency parameter

I think default max concurrency should be still one following the example of the Go client

Should we deprecate is_async parameter (seems redundant and a bit misleading now)

Yes we should deprecate this, probably do the same with subscribe_async, document that this is controlled by the concurrency level field now. We can do this in a separate PR.

[maruqu]

@wallyqs can you fix ClientTLSTest tests and document the changes in next PR?

[wallyqs]

Sorry the the TLS certs needed and update for the tests to pass (fixed via https://github.com/nats-io/nats.py/pull/123), if you rebase you should get the changes now.

[maruqu]

@wallyqs What do you think? Did I go too far with the refactor?

[wallyqs]

@maruqu I think it looks great! Also good to have a few things cleaned up finally

[maruqu]

@wallyqs I am glad I could help. Can you release a new package version containing this change? Maybe an alpha?

[hvt]

Is this the MaxInFlight behavior of the Go client?

[Positron1990]

Will anybody resolve this PR or it will be other concurrency level tools in the library?