feat(plugin-keychain-memory): add observability via RxJS ReplaySubjects

[petermetz]

1. This is an example of how to add observability to a plugin such as if you had to somehow expose the stream of transaction execution requests flowing through a connector plugin but did not feel like setting up Kafka or RabbitMQ just for this and instead opted to do it with an in-process, purely NodeJS/Javascript based solution.
2. The downside of this is of course that this doesn't work well in a distributed computing environment just by itself, since if you were to host a fleet of servers running the same connector plugin with horizontal scaling, then this wouldn't be able to observe all the invocations across the server fleet, but it would still make it easier to implement a functionality like that.
3. The main purpose of this pull request is educational. The keychain memory plugin is only used for testing and demonstration purposes and I wanted to show to a few other contributors what I meant when I was explaining that they could just use RxJS subjects to allow consumers of the connector plugins to observe the stream of transactions flowing through said connector plugin instance.

Signed-off-by: Peter Somogyvari [email protected]

Pull Request Requirements

• [x] Rebased onto upstream/main branch and squashed into single commit to help maintainers review it more efficient and to avoid spaghetti git commit graphs that obfuscate which commit did exactly what change, when and, why.
• [x] Have git sign off at the end of commit message to avoid being marked red. You can add -s flag when using git commit command. You may refer to this link for more information.
• [x] Follow the Commit Linting specification. You may refer to this link for more information.

Character Limit

• [x] Pull Request Title and Commit Subject must not exceed 72 characters (including spaces and special characters).
• [x] Commit Message per line must not exceed 80 characters (including spaces and special characters).

A Must Read for Beginners For rebasing and squashing, here's a must read guide for beginners.

[RafaelAPB]

I think this is good because other plugins need this feature (namely a plugin to do cross-chain security being developed now). This way we can reduce more complex dependencies such as RabitMQ. However, @outSH might be right in the sense that documentation might suffice. Thanks for the code @petermetz.

[petermetz]

@RafaelAPB @outSH I'd want to keep it in a code package instead of a docs folder because otherwise it's not getting compiled & tested with the rest of the project and as the code rusts it breaks over time and then the documentation becomes wrong. With that said, I agree with the larger point and what I'm thinking is that the entire package could be renamed to something else that better signifies that it's not for production, I just don't know what that name would be, but I'm open to trying to come up with something for sure.