[Networking] Clean underlay

[thep2p]

Problem:

Two LightChain nodes communicating with each other in the current version of code are using JavaRMI. The RMI implementation is tightly coupled with the LightChain protocol code which introduces the following downsides:
1- There is no clean-cut between protocol and network: The LightChain protocol implementation should not be aware of the implementation details of the network layer, which is not the case, e.g., here). It needs to just use the network for sending and receiving messages and should not be bothered about how it is sending and receiving the message. All implementation logics should be completely abstracted away from the network layer.

2- Lack of modularity: we cannot swap in and out the RMI with other underlying implementations.

Solution:

• We are going to inspire from our clean Skip Graph project architecture (it is a separate project and we are not going to follow it up exactly, rather we are going to absorb the idea and implement it similarly here).
• The only thing the LightChain protocol should know about the protocol is an Underlay interface that can interact with to send and receive messages. Look at how underlay is implemented in Skip Graph project
• All network-layer interactions (i.e., those directly interact with primitives like RMI) should lay behind the Underlay and completely abstracted away.
• Similar to what we have done in the Skip Graph project, it should be only Underlay that knows about RMI shared methods. The LightChain protocol should be completely unaware of such implementation. At the protocol level, we should use the request type, and translate the request to proper RMI call at the underlay.

Definition of Done:

• We have an Underlay interface that abstracts away the entire networking primitives.
• The only functionality that LightChain protocol is aware of networking is this new Underlay interface.
• Underlay is implemented at the broadest level of abstraction with minimum endpoints basically sending and receiving messages of general types. As a general rule, Underlay in LightChain should not have any more number of methods than Underlay in Skip Graph project.
• New functionalities completely covered by tests.

Development rules:

• Fork a branch in the form of yourname/issuenumber-issuetopic from master.
• Develop on the branch.
• Make sure that your code is well-commented, documented, supported by tests, and clean.
• The code should not add any commented functionality. If you comment something out, it means that you should completely remove it.
• Open the PR and make sure that it passes the pipeline.
• Important note: Your PR should not change more than 200 lines of code. If the surface of your PR is large, please break it into smaller ones, each completely passing the CI pipeline and able to merge, and open them one-by-one, i.e., open the first micro-PR, let it be reviewed and merge, and go with the second.

[thep2p]

Test cases we should cover:

• When both underlays A and B are up and ready, their exchanged messages are delivered to each other intact.
• When A is down, B sending a message to A is gracefully notified of unsuccessful delivery. Here, by a graceful delivery we mean through a returned parameter or state variable, and without interfering with the normal flow of the program, throwing an exception, or causing to crash.
• Above test cases also covered for multiple messages being sent both sequentially and concurrently.