Fix message body reading

[Sild]

Hello again

Message body parsing fix

I have been playing around with lite and tonlib api to check if we can migrate safely

For one of my tests I found the difference between message body parsing

Blockchain just read data cell till the end with it's references, but ton-lab-block checks if cell is empty - and treat such empty cell as None.

However people are inventive and usually put message body right into cell reference. So it worth to read it anyway (that's match with tl description - body is not optional, it's always presented).

After fixing it data matches with tonlibjson

Example of mismatch:

db_msg: Message { source: "EQDy_hPG41yzzb7aq1p50Nx1-cKlZQPM0Bcwaxg1Jf8-EXeX", destination: "EQBgiwfwAWgiKQV1h3BxgvqKdP63mwrCvwAVFreK4ZspOB9I", created_lt: 48241608000002, header: [181, 238, 156, 114, 1, 1, 1, 1, 0, 90, 0, 0, 175, 104, 1, 229, 252, 39, 141, 198, 185, 103, 155, 125, 181, 86, 180, 243, 161, 184, 235, 243, 133, 74, 202, 7, 153, 160, 46, 96, 214, 48, 106, 75, 254, 124, 35, 0, 24, 34, 193, 252, 0, 90, 8, 138, 65, 93, 97, 220, 28, 96, 190, 162, 157, 63, 173, 230, 194, 176, 175, 192, 5, 69, 173, 226, 184, 102, 202, 78, 16, 23, 215, 132, 0, 6, 30, 92, 250, 0, 0, 87, 192, 63, 209, 4, 4, 205, 97, 118, 245], state_init: Some([181, 238, 156, 114, 1, 1, 4, 1, 0, 100, 0, 2, 1, 52, 2, 1, 0, 75, 128, 30, 95, 194, 120, 220, 107, 150, 121, 183, 219, 85, 107, 79, 58, 27, 142, 191, 56, 84, 172, 160, 121, 154, 2, 230, 13, 99, 6, 164, 191, 231, 194, 37, 54, 65, 243, 16, 1, 20, 255, 0, 244, 164, 19, 244, 188, 242, 200, 11, 3, 0, 80, 211, 51, 49, 208, 211, 3, 1, 113, 176, 145, 91, 224, 250, 64, 48, 237, 68, 208, 250, 64, 48, 199, 5, 242, 225, 147, 147, 32, 215, 74, 151, 212, 1, 129, 0, 160, 251, 0, 232, 48]), body: [181, 238, 156, 114, 1, 1, 1, 1, 0, 2, 0, 0, 0], data_to_ref_flags: 0 }
tonlib_msg: RawMessage { source: AccountAddress { account_address: "EQDy_hPG41yzzb7aq1p50Nx1-cKlZQPM0Bcwaxg1Jf8-EXeX" }, destination: AccountAddress { account_address: "EQBgiwfwAWgiKQV1h3BxgvqKdP63mwrCvwAVFreK4ZspOB9I" }, value: 100000000, fwd_fee: 994941, ihr_fee: 0, created_lt: 48241608000002, body_hash: [242, 206, 246, 75, 123, 73, 23, 97, 50, 179, 138, 138, 13, 164, 167, 110, 174, 28, 112, 68, 7, 201, 33, 69, 102, 9, 125, 147, 139, 162, 160, 192], msg_data: Raw { body: [181, 238, 156, 114, 65, 1, 4, 1, 0, 190, 0, 1, 0, 1, 1, 96, 98, 0, 121, 43, 92, 215, 78, 57, 35, 42, 153, 75, 121, 125, 9, 16, 31, 51, 8, 91, 132, 66, 9, 148, 190, 231, 74, 190, 35, 185, 254, 120, 233, 127, 128, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 2, 1, 182, 15, 138, 126, 165, 104, 3, 45, 156, 74, 183, 119, 99, 112, 128, 244, 145, 3, 123, 32, 8, 1, 229, 252, 39, 141, 198, 185, 103, 155, 125, 181, 86, 180, 243, 161, 184, 235, 243, 133, 74, 202, 7, 153, 160, 46, 96, 214, 48, 106, 75, 254, 124, 35, 0, 60, 191, 132, 241, 184, 215, 44, 243, 111, 182, 170, 214, 158, 116, 55, 29, 126, 112, 169, 89, 64, 243, 52, 5, 204, 26, 198, 13, 73, 127, 207, 132, 72, 2, 98, 90, 1, 3, 0, 80, 0, 0, 0, 0, 50, 53, 55, 53, 49, 102, 54, 101, 45, 53, 100, 53, 57, 45, 52, 55, 55, 100, 45, 56, 55, 54, 55, 45, 50, 49, 50, 99, 49, 52, 52, 102, 56, 99, 52, 51, 154, 196, 74, 25], init_state: [181, 238, 156, 114, 65, 1, 4, 1, 0, 100, 0, 2, 1, 52, 1, 2, 1, 20, 255, 0, 244, 164, 19, 244, 188, 242, 200, 11, 3, 0, 75, 128, 30, 95, 194, 120, 220, 107, 150, 121, 183, 219, 85, 107, 79, 58, 27, 142, 191, 56, 84, 172, 160, 121, 154, 2, 230, 13, 99, 6, 164, 191, 231, 194, 37, 54, 65, 243, 16, 0, 80, 211, 51, 49, 208, 211, 3, 1, 113, 176, 145, 91, 224, 250, 64, 48, 237, 68, 208, 250, 64, 48, 199, 5, 242, 225, 147, 147, 32, 215, 74, 151, 212, 1, 129, 0, 160, 251, 0, 232, 48, 35, 152, 29, 76] } }
tx: 48241608000001:816c86b46e8801ad8f331414f956d9c3501a9db024e6f50416e58be2823b7a27

As you can see, body part in db_data (data from ton-labs-block) basically shows empty cell (I serialized None as empty cell). While tonlib body boc is not empty at all.

Helper functions

Sorry for putting it at the same PR.

That's required for our data serialization - to save some space, we split Message to different parts and store it separately in DB.

But when we need to build Message (and Transaction) back, we must know how exactly these parts were stored (otherwise we get transaction hash mismatch)

Hope these changes small enough to pass review =)

[Danyalkasiri]

README.md