Refactor backing storage and add frame construction functionality

[kortemik]

Description
Refactor rlo_06 so that:

Functional requirements

• It takes ByteBuffer[] as an input instead of a Streamable (existing interface within rlo_06)
• There is separate linefeed framing package that can be used before feeding data to rlo_06. Currently linefeed framing is within MsgFunction object.
• Add functionality from https://github.com/teragrep/rlo_14 so rfc5424 frames can be constructed as well instead of being only parsed.
  • rlo_06 replaces rlo_14
  • allow providing ByteBuffer[] in addition to Strings as arguments

Technical requirements

• It uses ByteBuffers as backing storage
  • No new Buffers are allocated while the source of the data is a ByteBuffer[], use slices instead. See https://github.com/teragrep/rlp_03/blob/main/src/main/java/com/teragrep/rlp_03/frame/fragment/clocks/PayloadLengthClock.java for reference.
  • Any memory allocation required for data is backed by a BufferLeasePool from https://github.com/teragrep/net_01/tree/main/src/main/java/com/teragrep/net_01/channel/buffer instead of allocating new memory.
  • Once a frame is closed memory must be freed back to the BufferLeasePool
  • Once a frame is closed it's methods must return an IllegalStateException
• Performance is the same or preferably increases as memory allocations lessen.
  • For reference on Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz with configured Memory Speed: 2667 MT/s:

[INFO] Running com.teragrep.rlo_06.tests.PerformanceTest
testShortPayloadPerformance: time taken 28916 for 10000000, total RPS: 345829.28, 6818.0 megabytes (235.7864 MB/s)
testMediumLongSDPerformance: time taken 405 for 25000, total RPS: 61728.395, 109.0 megabytes (269.1358 MB/s)
testDashes: time taken 15509 for 100000000, total RPS: 6447869.0, 1525.0 megabytes (98.33 MB/s)
testLongPayloadPerformance: time taken 18215 for 50000, total RPS: 2744.9905, 6137.0 megabytes (336.9201 MB/s)
testVeryLongSDPerformance: time taken 18494 for 500, total RPS: 27.035795, 740.0 megabytes (40.012978 MB/s)

Administrative requirements

• It respects Elegant Object principles https://www.elegantobjects.org/
• Update readme accordingly
• Comment the code
• Use object names describing the responsibilities of an object
• Expected values and input data in the test cases are not modified
• New test cases are added as needed.
• Allocate objects as few responsibilities as feasible.
• Use test drive development (TDD)
• Provide holistic commits with clear commit messages

[kortemik]

@eemhu @51-code please comment the usual stuff that are expected from a good quality project. This is a task for a bounty hunter and they are not aware how we do things.

[eemhu]

Some of the things that came to mind:

• Make sure the code is easily understandable with minimal comments needed
• No null assignments
• Each object should have a clear responsibility and collaborators.
• Objects should use as little code as possible, if an object requires a lot of code, it is more than likely that the object needs to be rethought and separated into multiple objects.
• Each new test should test each new object.
• Do not use try-catch in tests, assert that a exception should or should not be thrown instead.
• Make sure that the code is run in tests, for example when using loops, make sure the loop is executed the expected amount of times, especially when asserting within a loop.
• Make the pull request easily reviewable, do not make too many changes in one pull request.
• Fail-fast instead of fail-safe: When an error is encountered, throw an Exception rather than trying to fix it behind the scenes.