grpc-js: Fix call ref timer handling

[murgatroid99]

I think this change fixes the bug described in #2586 (comment).

The purpose of the callRefTimer is to hold the process open as long as there are calls that the channel is responsible for tracking because they are queued to either get a config from the resolver, or get a pick from the LB policy. Once a call becomes attached to a connection, that connection takes over tracking it and the responsibility for holding the process open. The general callRefTimer workflow goes like this:

• An update comes in from either the resolver or the LB policy
• The corresponding queue is emptied
• The timer is unreffed
• Each call is prompted to process that update
• If any call needs to requeue, that will cause the timer to be reffed

Once a resolver update has been received, calls never queue for configs anymore, they get them immediately after being created. And calls only queue for picks once they have a config. So, there is never a case when both queues are in use at the same time. The problem before this change is that if an update comes in from the resolver after the initial resolver update while there are calls in the pick queue, the timer would be unreffed but there would be no calls in the config queue, so nothing would trigger reffing the timer again. The fix is to only unref the timer if there is at least one call in the queue to process. I added the same condition to all call sites for consistency.

[silentroach]

cool, thank you!

[murgatroid99]

@silentroach This change has been published in grpc-js 1.9.13