fix: Reply time calculation for re-opened conversations (#11787)

This PR fixes the reply time calculation for reopened conversations.
Previously, when a customer sent a message to reopen a resolved
conversation, the reply time metric would be calculated incorrectly
because the `waiting_since` timestamp was not properly set before the
reply event was dispatched. This would create a case where you'd have
reporting events like the following

```
[[33955732, "reply_time", 19.0],
 [33955847, "reply_time", 24.0],
 [33955666, "reply_time", 89.0],
 [33955530, "conversation_bot_handoff", 4.0],
 [33955567, "first_response", 42.0],
 [33955745, "reply_time", 21.0],
 [33955934, "reply_time", 49.0],
 [33955906, "reply_time", 121.0],
 [33987938, "conversation_resolved", 26285.0],
 [35571005, "reply_time", 985492.0]]
```
Note the `reply_time` after `conversation_resolved`

The fix ensures that `waiting_since` is correctly updated when
conversations are reopened, either through incoming messages or manual
status changes, resulting in accurate reply time metrics that measure
only the time from the customer's new message to the agent's response.

## Type of change

Please delete options that are not relevant.

- [x] Bug fix (non-breaking change which fixes an issue)

## How Has This Been Tested?

The changes have been tested with comprehensive specs that verify:

1. **Reply time calculation after conversation reopening** - Ensures
correct timestamps are used when calculating reply times for reopened
conversations
2. **Waiting since updates on status changes** - Verifies that
`waiting_since` is properly set when conversation status changes from
resolved to open
3. **Test the happy path** - Happy path is tested to ensure the
`reply_time` and `first_response_time` is correctly calculated

Test instructions:
1. Create a conversation with the last message from a customer and
resolve it
2. Have an agent reopen it and reply to it
4. When an agent replies, verify that the agent reply_time event is not
created for this message

To fix any existing data, I've written a small script:
https://gist.github.com/scmmishra/fdf458863f2d971978327bbfd5232d0c

---------

Co-authored-by: Muhsin Keloth <muhsinkeramam@gmail.com>

app/listeners/reporting_event_listener.rb

@@ -47,6 +47,10 @@ class ReportingEventListener < BaseListener
     message = extract_message_and_account(event)[0]
     conversation = message.conversation
     waiting_since = event.data[:waiting_since]
+
+    return if waiting_since.blank?
+
+    # When waiting_since is nil, set reply_time to 0
     reply_time = message.created_at.to_i - waiting_since.to_i
 
     reporting_event = ReportingEvent.new(

app/models/conversation.rb

@@ -198,11 +198,21 @@ class Conversation < ApplicationRecord
   private
 
   def execute_after_update_commit_callbacks
+    handle_resolved_status_change
     notify_status_change
     create_activity
     notify_conversation_updation
   end
 
+  def handle_resolved_status_change
+    # When conversation is resolved, clear waiting_since using update_column to avoid callbacks
+    return unless saved_change_to_status? && status == 'resolved'
+
+    # rubocop:disable Rails/SkipsModelValidations
+    update_column(:waiting_since, nil)
+    # rubocop:enable Rails/SkipsModelValidations
+  end
+
   def ensure_snooze_until_reset
     self.snoozed_until = nil unless snoozed?
   end