Avoid timeouts for cancelling command

[jongyeol]

Make sure that:

• You have read the contribution guidelines.

• You use the code formatters provided here and have them applied to your changes. Don’t submit any formatting related changes.

• You submit test cases (unit or integration tests) that back your changes.

When an AsyncCommand was cancelled in another thread, LettuceFutures#awaitOrCancel() waited for long time and a timeout exception occured. So, I updated AsyncCommand#cancel() method using latch#countDown(), it'll occured an cancelled exception directly without meaningless waiting.

Previously:

Caused by: com.lambdaworks.redis.RedisCommandTimeoutException: Command timed out
    at com.lambdaworks.redis.LettuceFutures.await(LettuceFutures.java:98)
    at com.lambdaworks.redis.LettuceFutures.awaitOrCancel(LettuceFutures.java:77)
    at com.lambdaworks.redis.commands.AsyncCommandInternalsTest.cancelWhileAwaitWithException(AsyncCommandInternalsTest.java:89)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:497)
    at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
    at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
    at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
    at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
    at org.junit.internal.runners.statements.ExpectException.evaluate(ExpectException.java:19)
    ... 19 more

[coveralls]

Coverage increased (+0.3%) to 93.178% when pulling a8e2219df03ed7efe3563d694426fc8ffc95a93f on jongyeol:feature/add-latch-for-cancel into 92cd88b on mp911de:master.

[mp911de]

Thanks for your pull request. Lettuce uses/relies currently on java.util.concurrent.CancellationException to signal canceled commands. Releasing the wait semaphore to avoid timeouts is the right approach but I'm not convinced of introducing another exception. java.util.concurrent.CancellationException is raised by the Future and would require exception translation in other places, too.

[mp911de]

The latch should be released after invoking cancellation to avoid a state in which the latch is released but the Future is not canceled yet. I think wrapping the two cancel calls into a try and releasing the latch in finally should do the job.

[jongyeol]

@mp911de , I agreed about it. then, I'll update this soon. :)

[mp911de]

No need to rush. I'm traveling this week, won't be able to do much.

[jongyeol]

I don't want to disturb your travel. Please check it after your travel~

[coveralls]

Coverage increased (+0.2%) to 93.1% when pulling b635f76 on jongyeol:feature/add-latch-for-cancel into 92cd88b on mp911de:master.

[mp911de]

Thanks for the PR. That's merged with ee3a2f7.