[teamd] prevent re-entrance of port priv change handler

[yxieca]

- What I did

This change addresses an issue introduced by #2699

When adding a lag member dynamically after system boots up, teamd
port priv change handler could re-entrant itself and causing adding
operation to fail.

While handling PORT_CHANGE event, teamd_per_port.c port priv change
handler was called, it will then call runner_lacp to add port to lag,
the later causes IFINFO_CHANGE to be notified and calls the priv change
handler again, this re-entrance would cause runner_lacp port_added to
be called again and messes up with the previous adding sequence. Then
fails the lag member adding operation.

Prevent per port priv change handler re-entrance solves the problem.

Signed-off-by: Ying Xie ying.xie@microsoft.com

- How to verify it

1. Passed incremental config nightly test over the weekend.

2. Manually tested add a member port to a lag.

3. 897 iterations of continuous warm reboot: 338 with [teamd] retry creating team_port after interface info changed #2699 only. And 559 with [teamd] retry creating team_port after interface info changed #2699 plus this change (test still running):

yinxi@acs-trusty8:/warmboot/cont_wb$ grep Rebooting wb-test-20190328-0631.log | grep 20190329 | wc -l
559
yinxi@acs-trusty8:/warmboot/cont_wb$ grep Rebooting wb-test-20190328-0631.log | grep -v 20190329 | wc -l
338

[jipanyang]

I feel that we need to drill down the root cause of that device name missing issue. Patching with all the workaround doesn't seem to be a long term solution.

[yxieca]

@jipanyang I agree with you. That might take longer time. If we identify the root cause and proper fix. I don't mind revert this change and #2699.

Frankly speaking, I thought about this. I think the other way to fix the issue is to delay creating LAG devices after warm reboot. But I don't know a good indication of 'readiness' to do so.