messagechannel.send() implementation

[kmrdhruv]

Closes #94

• Implements only send(). publish() and request() to be implemented as needed.
• Tests to be added post initial review.

[github-actions]

Test Results

213 tests   213 ✅  34s ⏱️
 47 suites    0 💤
 47 files      0 ❌

Results for commit 1f43d2e.

♻️ This comment has been updated with latest results.

[codecov-commenter]

Codecov Report

Attention: 19 lines in your changes are missing coverage. Please review.

Comparison is base (08f81cf) 72.37% compared to head (f571f2c) 72.08%.

Files	Patch %	Lines
...m/flipkart/varadhi/cluster/MessageChannelImpl.java	59.09%	16 Missing and 2 partials ⚠️
...flipkart/varadhi/core/cluster/ResponseMessage.java	0.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #102      +/-   ##
============================================
- Coverage     72.37%   72.08%   -0.30%     
- Complexity      502      510       +8     
============================================
  Files           101      103       +2     
  Lines          2201     2246      +45     
  Branches        135      138       +3     
============================================
+ Hits           1593     1619      +26     
- Misses          555      572      +17     
- Partials         53       55       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[gauravAshok]

add / remove methods dont look like they belong here. They can only remain in Impl class I think.

[gauravAshok]

Suggested change

	<E extends ClusterMessage> CompletableFuture<ResponseMessage> request(E message);
	<E extends ClusterMessage> CompletableFuture<ResponseMessage> handleRequest(E message);

Does the params need sender info? E message might not have sender info.

[gauravAshok]

Are the checks like "DELIVERY_KIND_SEND.equals(deliveryKind)" required?

Feels redundant. I thought that "expecting" response is kinda implicit due to the api.

For these things to work properly. the sender and reciever needs to be compatible. But having this header does not make it "correct" or enforce correctness.

For eg:
sender could have just "Send" but here we are registering a consumer which actually returns something. So does it mean that the "sender" establishes the expectation of "no response"? But consumer has a response so, is that correct?

The vice-versa is that consumer establishes expectation that there will be response and it is upto sender to ignore that or use that?

Frankly neither feels 100% correct. Which means that the correctness / compatibility enforcement is "implicit". If we get it wrong, well we should have tested it, but there is no way to enforce that in runtime. So the "deliveryKind" header effectively looks redundant as it is not bringing any more validations.