Added support for fromBlock when generating eventservice cache keys

[jimthematrix]

The current cache key only takes into account the channel ID, which means if I have a different fromBlock number, or chaincode Id with a subsequent RegisterBlockEvent() call, it would not take effect because the previous event service will be returned from the cache lookup.

[codecov]

Codecov Report

Merging #184 (2ae5ea6) into main (e866365) will increase coverage by 0.06%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main     #184      +/-   ##
==========================================
+ Coverage   76.15%   76.21%   +0.06%     
==========================================
  Files         193      193              
  Lines       14077    14098      +21     
==========================================
+ Hits        10720    10745      +25     
+ Misses       2388     2385       -3     
+ Partials      969      968       -1     

Impacted Files	Coverage Δ
pkg/client/channel/chclientrun_std.go	100.00% <ø> (ø)
pkg/fabsdk/fabsdk_std.go	100.00% <ø> (ø)
pkg/client/event/event.go	85.00% <100.00%> (+6.05%)	⬆️
pkg/client/event/opts.go	100.00% <100.00%> (ø)
pkg/fab/events/deliverclient/opts.go	100.00% <100.00%> (ø)
pkg/fabsdk/provider/chpvdr/cachekey.go	84.00% <100.00%> (+7.80%)	⬆️

---

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 e866365...2ae5ea6. Read the comment docs.

[kopaygorodsky]

Hey @jimthematrix, are you going to continue working on this PR (fix tests, code coverage)? I've stumbled on this issue as well and would like to help if this PR is stale.

[jimthematrix]

@kopaygorodsky thanks for offering to help, I haven't been able to get back to this one. if you are able to spare some cycles on the tests that'd be much appreciated!

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[kopaygorodsky]

@bstasyszyn hey, this PR raised a problem related to the lazycache component. Each event client with a different starting block number is a new entry in the cache. It has some idling timeout and then calls finalizer which closes the connection and resets Ref to nil, but the key in the cache stays. One of my environments has very often reconnections with increasing block number param each time so in a week it resulted in 200Mb of keys in the cache.
I see three possible solutions to this problem:

• IOC of the context.ChannelProvider in the constructor of the event client. It gives the user ability to create channel context and close it manually. On CloseContext all cached are cleaned.
• By fixing the reset mode of the Reference. Put the link of the Cache into the Reference so it can clean up its key in the handleExpiration method.
• Add the DeleteOnlyKey method to the cache, so it just deletes the key without calling close(). In that way a callback with that method can be put into a custom finalizer.

[kopaygorodsky]

@bstasyszyn