Support varint to have a better list size encoding

[ghost]

Is your feature request related to a problem?

We are using some fixed int sizing for the encoding, for example in the list or binary encoding from estimation or approximation. (ex: 1 byte = 256 elements in a list)
However, this approach is not scalable and inefficient as it can either limit the number of items or use too big encoding and useless bytes.

Describe the solution you'd like

To tackle this problem, we can leverage Variable length integers (varint): an encoding format which compress down integers into a smaller space than is normally needed. So we can save bandwidth. The idea is smaller numbers are more common in than larger ones.
So the trade-off is to spend more bits on larger numbers, and fewer bits on smaller numbers.
Example: a 64-bit integer that is almost always less than 256 would be wasting the top 56 bits of a fixed width representation.

There are several approaches of this problem:

• Continuation bits: https://developers.google.com/protocol-buffers/docs/encoding#varints (Base-128 encoding)
• Length prefixed: https://developer.bitcoin.org/reference/transactions.html#compactsize-unsigned-integers

While Protobuf's approach seems interesting, it's still quite complex using bits manipulation.
The benefit of length prefixed is the simplicity of understanding and fast decoding.

So we can leverage such technique as length prefixed but we can simplify it a bit using a simple byte to identify how many bytes the following integer is encoded:

• x: >= 0 && x <= 2⁸: <<1::8, x::8>> -> 1 byte
• x > 2⁸ && x <= 2¹⁶: <<2::8, x::16>> -> 3 bytes
• x > 2¹⁶ && x <= 2³²: <<3::8, x::32>> -> 5 bytes
• x > 2³² && x <= 2⁶⁴: <<4::8, x::64>> -> 9 bytes

Additional context

Should be implemented for the infinite sizes (input list, etc...)

[prix-uniris]

There's a clear advantage in proto-buf to support the greater length of integers.
But in the case of bitcoin encoding, we have to pre-define how much is the length of our integers can be or a range, so if we want to support say, u128 then we will be required to account for then they will make use of 0xfc as last one byte range and following simply as per their scheme.
The above encoding, is a good option also, as it will add 1 byte as the integer length as prepend to the integer itself, so this can also work fine.
This would be a great serialization technique which is simpler as in our stack we use bitstring, also protobuf, is a better alternative which is bit complex them simple encoding read as mentioned above.

[ghost]

Hey team! Please add your planning poker estimate with ZenHub @apoorv-2204 @imnik11 @Neylix @prix-uniris

[prix-uniris]

Tasks/Actions

• Make a Util Module to encode and decode variable length number
• Make changes in codebase wherever lists are being used
  • Transaction Data Fields
  • Transaction
  • Encoder (DB)
  • Validation TimeStamps
• Make Changes for the same in decoding
• Modify Doctests for the same
• Modify/Update Tests for new Encoding