Move ZMQ socket bind to poll thread to prevent orch blocking

[ypcisco]

Why I did it

• In scale scenarios, zmq_bind() can take significant time to complete
• Orchestration agent gets blocked during ZmqServer initialization
• Synchronous bind in main thread delays startup and impacts system responsiveness

How I did it

• Moved zmq_bind() call from ZmqServer::bind() to mqPollThread()
• Socket creation and configuration remain in main thread
• Actual bind operation now happens in background poll thread

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[anish-n]

Approve, but I would request Qi or someone else with more context on this aspect to review

[prsunny]

@ypcisco , can you fix coverage? @qiluo-msft , please review

[qiluo-msft]

Could you provide evidence (logs, profiling data) showing that zmq_bind() itself is the bottleneck?

[qiluo-msft]

This thread has NO catch-all block. Throwing exception will crash the process immediately.

[ypcisco]

I think that was the intention of the original code to terminate the process and not silently log the msg.

[ypcisco]

Could you provide evidence (logs, profiling data) showing that zmq_bind() itself is the bottleneck?

Here are some logs showing how zmq_server bind is blocking the orch.

Syslogs :

2025 Jun 26 15:19:12.294637 sonic NOTICE swss#orchagent: :- main: Attempting to bind ZMQ server to tcp://127.0.0.1:8100...  >>>> This log was added for debugging just before zmq_server->bind() call itself
2025 Jun 26 15:23:22.548010 sonic NOTICE swss#orchagent: :- main: ZMQ channel on the northbound side of Orchagent successfully bound: tcp://127.0.0.1:8100, 

Swss.rec :

2025-06-26.15:18:42.506924|recording started
2025-06-26.15:23:22.549016|CRM|Config|SET|acl_counter_high_threshold:85|acl_counter_low_threshold:70|acl_counter_threshold_type:percentage|acl_entry_high_threshold:85|acl_entry_low_threshold:70|acl_entry_threshold_type:percentage|acl....