Fix/mqtt publish hanging

[jehanshah8]

Fix robot status hang issue with best-effort publishing

Problem
Applications using the EdgeSDK would hang indefinitely when _send_robot_status() called wait_for_publish() without a timeout, particularly during network instability or MQTT reconnection attempts. This caused connectors to appear frozen while still consuming resources, leading to poor user experience and operational issues.

Solution
Replaced the blocking status publishing approach with a best-effort, non-blocking implementation that eliminates hanging while maintaining status accuracy through InOrbit's multi-layer detection system.

Key Changes
Removed blocking wait_for_publish() calls that could hang indefinitely
Direct client.publish() with exception handling for immediate, non-blocking status updates
Eliminated threading complexity from _on_connect while preserving functionality

Resilience Design
InOrbit's detection system provides multiple fallback layers when status publishing fails:
Data message detection - InOrbit detects when "offline" robots send data and requests status updates
Ping-based detection - Active pinging with automatic offline marking after failed attempts
Timeout-based cleanup - Stale connection detection and cleanup
InOrbit Status Request Flow: When InOrbit receives data from a robot marked as offline (if connection goes through but status update does not in _on_connect()), it automatically sends a get_state command requesting the robot to re-send its status. This means best-effort status publishing in EdgeSDK is not problematic - if the initial status fails, InOrbit will detect the discrepancy through data flow and explicitly request an update. Applications using EdgeSDK (like connectors) can implement get_state handlers to respond to these requests with accurate robot state information.
Note: The get_state command handler should be implemented at the connector level (not EdgeSDK) to provide intelligent robot state assessment based on actual robot connectivity, not just MQTT connection status. This way the connector can also decide how to publish status when the connector is online but disconnected from robot.
This makes explicit status messages an optimization rather than a strict requirement for accurate online/offline detection.

[jehanshah8]

@leandropineda can I please get a quick re-review, code changes are trivial but need to make sure the design is good (see pr description)