Analytics timestamp records request completion time, not arrival time

[umyonghyun]

Branch/Environment/Version

• Branch/Version: master / Latest
• Environment: All

Describe the bug
The TimeStamp field in analytics records is being generated after the upstream response has been received. This causes the timestamp to reflect the request's completion time, rather than its initial arrival time at the gateway. This behavior is misleading for analytics and monitoring purposes.

Reproduction steps

1. Set up a Tyk Gateway with analytics enabled.
2. Configure an API to proxy to an upstream service that has a noticeable delay (e.g., https://httpbin.org/delay/2).
3. Send a request to the API through the Tyk Gateway.
4. Observe the generated analytics record for this request.
5. The TimeStamp field in the record will be approximately 2 seconds (or the delay duration) after the request was actually sent. The RequestTime (latency) field will correctly show the delay.

Actual behavior
The TimeStamp in the AnalyticsRecord reflects the time when the gateway has finished processing the request (i.e., after receiving the upstream response).

Expected behavior
The TimeStamp in the AnalyticsRecord should reflect the time when the request was first received by the Tyk Gateway, providing an accurate log of when events began.

Logs (debug mode or log file):
N/A - This is observable directly in the analytics data structure and logic.

Configuration (tyk config file):
This issue is independent of any specific configuration and is present in the core proxying logic.

Additional context
This issue was identified while analyzing the request lifecycle in gateway/reverse_proxy.go and gateway/handler_success.go. The fix involves capturing time.Now() at the beginning of the request chain in reverse_proxy.go, passing it through the request context, and using this value in handler_success.go when constructing the AnalyticsRecord.