Sync blocking enable/disable over redis (#377)

[kwitsch]

still needs some unittests

[codecov]

Codecov Report

Merging #403 (4db05f0) into development (04b21e4) will increase coverage by 0.12%.
The diff coverage is 91.66%.

❗ Current head 4db05f0 differs from pull request most recent head ea9f9d7. Consider uploading reports for the commit ea9f9d7 to get more accurate results

@@               Coverage Diff               @@
##           development     #403      +/-   ##
===============================================
+ Coverage        94.10%   94.23%   +0.12%     
===============================================
  Files               32       32              
  Lines             2546     2600      +54     
===============================================
+ Hits              2396     2450      +54     
- Misses             112      113       +1     
+ Partials            38       37       -1     

Impacted Files	Coverage Δ
redis/redis.go	67.97% <84.61%> (+6.25%)	⬆️
resolver/blocking_resolver.go	100.00% <100.00%> (ø)
resolver/caching_resolver.go	98.42% <100.00%> (ø)
server/server.go	89.22% <100.00%> (ø)

---

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 04b21e4...ea9f9d7. Read the comment docs.

[kwitsch]

@0xERR0R sorry it seem i still don't really get unit test. 😞
According to redis_test.go line 105-161 the lines codecov marks as untested should be covered.

[0xERR0R]

Thank you for your work! I'll try to review and test this PR this week. I see, you are using the same pub/sub channel as for the cache synchronization (by using coded message type as message field). What was the reason to reuse this channel and not to create a separate one only for enable/disable state (2 separate channels for 2 different messages). I guess you wanted to reuse the logic with client uuid?

[kwitsch]

Thank you for your work! I'll try to review and test this PR this week. I see, you are using the same pub/sub channel as for the cache synchronization (by using coded message type as message field). What was the reason to reuse this channel and not to create a separate one only for enable/disable state (2 separate channels for 2 different messages). I guess you wanted to reuse the logic with client uuid?

Yes i figured utilizing different channels would duplicate functionality on the client side.
Thought that ~3 byte in communication would cost less time than expensive logic on the client side.