[Woo POS] Modularization: refactor WaitingTimeTracker to remove Analytics dependency and move it to WooFoundation

[jaclync]

Part of WOOMOB-935

Description

Refactors WaitingTimeTracker to remove its Analytics dependency so that it can be moved to WooFoundation for future reuse across the app and Point of Sale (POS) module. The refactored WaitingTimeTracker is now a pure utility class that tracks time intervals and generates analytics events, while AppStartupWaitingTimeTracker serves as a wrapper that handles analytics tracking.

Key Changes:

• Moved WaitingTimeTracker from WooCommerce/Classes/Analytics/ to Modules/Sources/WooFoundation/Utilities/
• Removed direct Analytics dependency from WaitingTimeTracker
• WaitingTimeTracker now returns WooAnalyticsEvent objects instead of directly tracking events
• AppStartupWaitingTimeTracker wraps WaitingTimeTracker and handles analytics service interaction
• Updated all usage sites to work with the refactored architecture

Steps to reproduce

1. App Startup Waiting Time Tracking:

   • Launch the app from a fresh install or after force-closing, or switching stores
   • Verify app startup waiting time event is tracked in application_opened_waiting_time_loaded's waiting_time

2. Dashboard Performance Tracking:

   • Launch the app
   • Verify that dashboard main stats waiting time is tracked in dashboard_main_stats_waiting_time_loaded's waiting_time
   • Verify that dashboard top performers waiting time is tracked in dashboard_top_performers_waiting_time_loaded's waiting_time

3. Analytics Hub Tracking:

   • Navigate to My store tab > tap "View all store analytics" to visit Analytics Hub
   • Verify analytics hub loading time is tracked correctly in analytics_hub_waiting_time_loaded's waiting_time

4. Order Details Tracking:

   • Navigate to Orders → Select any order
   • Verify order details waiting time is tracked in order_detail_waiting_time_loaded's waiting_time

5. Point of Sale Tracking:

   • Tap on the POS tab
   • Verify POS loading time tracking works correctly in pos_loaded's milliseconds_time_elapsed_in_splash_screen

Testing information

• @jaclync tests the flows above.

---

• I have considered if this change warrants user-facing release notes and have added them to RELEASE-NOTES.txt if necessary.

[dangermattic]

	1 Warning
⚠️	View files have been modified, but no screenshot or video is included in the pull request. Consider adding some for clarity.

Generated by 🚫 Danger

[wpmobilebot]

📲 You can test the changes from this Pull Request in WooCommerce iOS Prototype by scanning the QR code below to install the corresponding build.

	App Name	WooCommerce iOS Prototype
	Build Number	pr16169-bdf07a1
	Version	23.3
	Bundle ID	com.automattic.alpha.woocommerce
	Commit	bdf07a1
	Installation URL	18vqbv7jcgv1o

Automatticians: You can use our internal self-serve MC tool to give yourself access to those builds if needed.

[staskus]

It's likely not related to this PR, but if you open the Woo app, and after some time change the site, the elapsed time is logged from the app launch up until the site change.

[jaclync]

I tested outside this PR, and confirmed the same behavior. It seems to be from the stats and onboarding tasks are always reloaded every app launch, and the completion of these reloads is required for logging the event:

woocommerce-ios/WooCommerce/Classes/Analytics/AppStartupWaitingTimeTracker.swift

Lines 40 to 43 in 83cfd68

	// If all actions completed without any errors, send the analytics event.
	if startupActionsPending.isEmpty {
	super.end()
	}

I'm guessing this event was for performance measurement (Eagle worked on it) while the stats/onboarding were always reloaded (it was the case before), then the app changed to not always reload the stats/onboarding tasks. AppStartupWaitingTimeTracker also doesn't get reset when switching stores, so the loading time could become inaccurately longer as the starting time was from app launch. But since this is pre-existing behavior, perhaps the team working on it could revisit this performance metric.