Port is not adding to portchannel when the port is removed from participating VLAN and not member of any VLAN.

[ramachandrareddygaddam]

- What I did
When is port added to any VLAN, Bridge port association is created and port is enslaved(/sys/class/net//master -> ../Bridge).
When port is removed from VLAN and the port is no more member of any VLAN, the VLAN---Bridge---Port association has to be cleaned up.
In SONiC, the VLAN manger code will check the VLAN membership association and detach the port from Dot1Q bridge, by invoking the Linux shell command (/sbin/ip link set nomaster).
Due to parsing issue, the Linux shell command is not taking place and not setting 'nomaster'.

In this state, when the port is configured to add to PortChannel, the operation is failed assuming that port is enslaved by others.

So, corrected the parsing logic to check the port is not member of any VLAN.

- How I did it
By using sed, grep utilities the parsing logic modified to check the port is part of any VLAN.
The bridge vlan show output is as follows.
root@sonic:~# /sbin/bridge vlan show dev Ethernet0
port vlan ids
Ethernet0 1 PVID Egress Untagged
1000

In the above example, the port is still member of VLAN 1000.
When port VLAN membership 1000 is removed and then port is not part of any VLAN;
Clear the bridge port association.
- How to verify it

1. Configure the VLAN and add physical port as member of VLAN.
2. Check port the correctly added as member of VLAN and verify the hardware entries.
3. Remove the physical port VLAN membership.
4. Create the PortChannel and add the same physical port as part of the PortChannel.
5. Execute 'teamshow' or 'show interfaces portchannel' and check port state is showing correctly.
6. Additionally can check for traffic flow.

Without fix:

The port is not added to PortChannel and configuration is the entry only present in config DB.
After the save and reload the configuration (or) reboot only, the physical port becomes the part of PortChannel.

[msftclas]

All CLA requirements met.

[ramachandrareddygaddam]

The changes #592 also required along with the fix.

[prsunny]

@ramachandrareddygaddam , is this PR required as you referenced #592 which is closed and also suggest latest kernel doesn't have that issue.