[fdborch] Batch-drain FDB notifications in FdbOrch::doTask

[manish1-arista]

What I did
In FdbOrch::doTask(NotificationConsumer&), replace the single consumer.pop() with consumer.pops() to drain a batch of pending entries on the notification channel per main-loop iteration instead of just one. The per-entry processing logic is factored unchanged into a new handleNotification() helper that doTask() dispatches each popped entry to.

No behavioral change for any individual notification, only the rate at which the queue is drained.

Why I did it
Under FDB event storms (large MAC moves etc), the producer side pushes notifications into the queue faster than the previous one-at-a-time drain could consume them. The backlog grew unboundedly, which on our deployments showed up as:

• orchagent RSS growth tracking the queue length
• in extreme cases, OOM / kernel panics on the device

NotificationConsumer::pops() already exists exactly for this pattern and is what some other orch agents (e.g. portsorch) use.

How I verified it
Built sonic-swss against the change cleanly.
The Queue length remains in check under mac storm.

Details if related

[mssonicbld]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[manish1-arista]

Our Batch Drain FDB Notification consumer queue approach targeted fdborch only, drain the batch of pending entries on the notification channel per main-loop iteration instead of just one.
We are are able to see that the FDB Notification consumer queue size was not increasing under Mac move storm.

The Other PRs (sonic-net/sonic-swss-common#1191, #4586 and sonic-net/sonic-sairedis#1899) fixes this memory growth for other orch consumer queue also by addressing the problem at the infrastructure layer rather than a single orch, by adding allowlist for each orchagent and Dedup queues for multiple orchangents.

Closing this PR as other PRs had merged