PMM-1035 Fix toast slice fetching with offset

[artemgavrilov]

https://perconadev.atlassian.net/browse/PG-1035

PG strings regression tests failed on section when it checks how substirng func works for toasted bytea data: https://github.com/postgres/postgres/blob/master/src/test/regress/sql/strings.sql#L575-L606

It seems that reason for that was that start_offset was calculated improperly. Looks like PG_TDE_DECRYPT_DATA should get start_offset alligned by chunk size, but when we copy data to result we can and should apply sliceoffcet.

[github-actions]

Performance test results:
Normal queries: 9126
TDE queries: 8809
Percentage: 96%

[dAdAbird]

Yes, sliceoffset is redundant in the decryption offset. sliceoffset points to the offset from the start of TOAST value and (curchunk * TOAST_MAX_CHUNK_SIZE - sliceoffset) + chcpystrt will get the offset for each chunk from the start of fetched data. But for decryption, we need the offset relative to the beginning of TOAST data.
For example:
SELECT substring(t, 6660, 5984) FROM toasttest; will get 4 chunks and sliceoffset would be 6659. And offset with the sliceoffset correlation for these chunks would be 0, 1325, 3321, and 5317 - offset relative to the beginning of the requested data - which is what we need for memcpy data into the buffer. But for decryption, we need 6659, 7984, 9980, and 11976 offsets - relative to the beginning of the TOASTed data.

[artemgavrilov]

@dAdAbird Thanks for an explanation!