[Utility] Feat: add client-side session cache

[adshmh]

Description

Add a client-side cache for sessions and use it in the servicer command.

Issue

Fixes #791

Type of change

Please mark the relevant option(s):

• New feature, functionality or library
• Bug fix
• Code health or cleanup
• Major breaking change
• Documentation
• Other

List of changes

• A session cache in the client package
• Use the new session cache in the servicer command

Testing

• make develop_test; if any code changes were made
• make test_e2e on k8s LocalNet; if any code changes were made
• e2e-devnet-test passes tests on DevNet; if any code was changed
• Docker Compose LocalNet; if any major functionality was changed or introduced
• k8s LocalNet; if any infrastructure or configuration changes were made

Required Checklist

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added, or updated, godoc format comments on touched members (see: tip.golang.org/doc/comment)
• I have tested my changes using the available tooling

If Applicable Checklist

• I have updated the corresponding README(s); local and/or global
• I have added tests that prove my fix is effective or that my feature works
• I have added, or updated, mermaid.js diagrams in the corresponding README(s)
• I have added, or updated, documentation and mermaid.js diagrams in shared/docs/* if I updated shared/*README(s)

[Olshansk]

Thoughts on making SessionCache an interface with an internal sessionCache implementation so its easy to see & understand how to interact with it?

[adshmh]

Not against it at all, and I have used the pattern, i.e. define a public interface and return an internal struct as the implementation, many times. However, Accept interfaces, return structs pattern is arguably a good substitute, as it matches the standard library. Either approach works here IMO, so please advise which you consider a better fit.

[Olshansk]

Let's do the following:

1. Define a public interface
2. Make the public interface conform to the Submodule interface
3. Define an internal struct
4. Have the factory function return the interface type (which is actually an initialization of the struct underneath)

[Olshansk]

Closing this out per @h5law's suggestion here: #888 (comment)

[Olshansk]

@adshmh Please re-request a review when this is ready

[h5law]

Left a bump on a previous comment, and for the few improve/todo comments that have been added the only minor NIT I could add would be to create a ticket to track them and add the issue number in the comment IMPROVE(#XXX) for example.

Otherwise everything looks good! Make sure to address the linter errors and I think this will be ready to merge then

[Olshansk]

Let's do the following:

1. Define a public interface
2. Make the public interface conform to the Submodule interface
3. Define an internal struct
4. Have the factory function return the interface type (which is actually an initialization of the struct underneath)

[adshmh]

Let's do the following:

1. Define a public interface
2. Make the public interface conform to the Submodule interface
3. Define an internal struct
4. Have the factory function return the interface type (which is actually an initialization of the struct underneath)

Thank you for the review. Fixed, except item 2, as conforming to the Submodule interface would require the underlying kvstore to also support Start method. In addition, IntegrableModule would require supporting SetBus and GetBus methods, which don't seem needed for the client side (please advise if I am missing something here). Updated the struct to private, added new public interface, and used Create to be more consistent with submodules style.

[h5law]

conforming to the Submodule interface would require the underlying kvstore to also support Start method. In addition, IntegrableModule would require supporting SetBus and GetBus methods, which don't seem needed for the client side (please advise if I am missing something here)

To be clear the Submodule interface only requires GetBus() SetBus() and GetModuleName(). That being said I do not think this needs to be a submodule as it does not require any access to/from the bus. That seems like overkill to me. @Olshansk is there a reason you can see to make this a submodule?

@adshmh Personally as this is not a submodule I would change your Create method to a NewSessionCache or similar name to avoid confusion with it being a submodule.

[Olshansk]

LGTM other than the one point from Harry.