Higher Resolution Request Timestamping

[kevinkreiser]

Within the request info objects we store a seconds-resolution timestamp value. We use this to perform request cancellation in the event a request is taking too long. Second-level resolution seems fine for this however... There are use-cases when it would be useful for a downstream application to get better timing information about when the request hit the server vs when the request hit the application code. Second-resolution is not good enough for this use-case. We should refactor the info struct to allow for subsecond (usec probably) resolution and make use of the gettimeofday function to populate this. The info struct is already inefficiently designed. it has 2 32 bit ints and 1 16 bit, the compiler will at the very least pad the latter to 32bits (on 32 bit platforms) and at worse pad out to 64bits. i'd argue that since most of our deployments will be targeting 64bit architectures it makes sense to just have 2 64bit in total leaving plenty of space for usec as well as space for future use. i know we bitwise or the id part and the timestamp part into one 64bit value for tracking the request but i cant remember if that is sorted, even so adding in the fractional part of the second for sorting is probably not critical so i'd propose we literally just add the tracking of this info and make no other functional changes at this time.