Fix Invocation Service group lost handling

[yuce]

This PR fixes group lost event handling in the Invocation Service:

• The subscriber to the group lost event in the invocation service should return if the invocation service is stopped.
• handleGroupLost relied on an atomic value for protection, which was wrong. Replaced that with a mutex.

[codecov-commenter]

Codecov Report

Merging #816 (21c0088) into master (69a3310) will decrease coverage by 0.01%.
The diff coverage is 94.11%.

@@            Coverage Diff             @@
##           master     #816      +/-   ##
==========================================
- Coverage   77.13%   77.11%   -0.02%     
==========================================
  Files         329      329              
  Lines       15547    15556       +9     
==========================================
+ Hits        11992    11996       +4     
- Misses       2709     2713       +4     
- Partials      846      847       +1     

Impacted Files	Coverage Δ
internal/invocation/invocation_service.go	79.26% <94.11%> (-0.09%)	⬇️
internal/cluster/cluster_service.go	75.87% <0.00%> (-1.32%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 69a3310...21c0088. Read the comment docs.

[utku-caglayan]

I think this works and understand the reasoning behind adding the doneChannel control. But I do not get replacing the atomic variable with a mutex-protected one. Can you share your reasoning on that one?

[yuce]

I think this works and understand the reasoning behind adding the doneChannel control. But I do not get replacing the atomic variable with a mutex-protected one. Can you share your reasoning on that one?

Atomic variable can protect only itself. They can be used to protect a block when used with compare and swap, but otherwise a mutex should be used. Line

hazelcast-go-client/internal/invocation/invocation_service.go

Line 252 in 69a3310

if atomic.LoadInt32(&s.state) != ready {

is not enough to protect the block below, since invocation service can stopped right after that if statement.

[nevzatseferoglu]

LGTM! Just a quick remark,s.executor.stop() use a waitgroup inside it. In case of any unintended infinite spinning on wait creates a deadlock on the invocation service state mutex.
https://github.com/hazelcast/hazelcast-go-client/blob/master/internal/invocation/stripe_executor.go#L80