port: Fix unicast negotiation doesn't recover after FAULT_DETECTED

_Problem_
After a port link down/up or a tx_timestamp timeout issue, a port acting
as unicast master does not issue ANNC messages after granting unicast
request for ANNC.

_Analysis_
When a port FAULT occurs, the port transitions to FAULTY on FAULT_DETECTED
and subsequently port_disable(p) and port_initialize(p) are called on port recovery.

A port acting as a unicast master, stores clients in p->unicast_service->queue.

When a port receives a unicast request, unicast_service_add() is called.

In unicast_service_add(), if the request does not match an entry in
p->unicast_service->queue, FD_UNICAST_SRV_TIMER is started via
unicast_service_rearm_timer().

If the unicast request matches an existing p->unicast_service->queue entry
the request is considered an extension and FD_UNICAST_SRV_TIMER must
already be running.

port_disable() clears FD_UNICAST_SRV_TIMER, ie. stops FD_UNICAST_SRV_TIMER.
However, port_disable() does not clear p->unicast_service->queue.
When the port is restarted, the port retains the previous client data.

After port recovery, when the client attempts to restart the unicast
service, the request matches an existing entry in p->unicast_service->queue,
and so FD_UNICAST_SRV_TIMER is not started because the port expected
that the FD_UNICAST_SRV_TIMER is already running.

_Fix_
This patch clears the unicast client data in port_disable() so
that upon recovery, the initial unicast request will be considered
a new request and trigger the start of the FD_UNICAST_SRV_TIMER.

v2:
- Add missing sign-off
- Send to develop-request instead of users list

Signed-off-by: Vincent Cheng <vincent.cheng.xh@renesas.com>