Moving Request ID to the Header of the Response DataTable in the Next Version

[jasperjiaguo]

Currently the requestID lives in the metadata of the response, at the end of the serialized bytes, making it harder for accountant code to track the deserialization memory of a particular query timely. This may cause OOM exceptions that's hard to map back to the actual query. Meanwhile, it can also be a blocker for the future resource management/scheduling work.

[siddharthteotia]

If there is alignment that we can do this minor change and bump the version to V5 (provided we don't have to duplicate rest of the code), then I think we should do it soon. Otherwise, we can fold it along with any other future major change that will require protocol and version change.

[ankitsultana]

There's also a long pending need to switch to uuid based requestIds. If we are doing data table version updates can we also consider adding support for this?

Integer based requestIds can have collisions since multiple brokers may have the same counter value. Right now the Multistage scheduler uses the long requestIds created by the broker for scheduling which can lead to weird scheduling bugs.