stress test task: allocate and deallocate tags from interfaces and links

[viniarck]

This is for stress testing the following cases with multiple threads trying to:

• 1. Allocate and deallocate many individual vlans on an interface
• 2. Allocate and deallocate a range of vlans on an interface
• 3. Allocate one individual vlan and deallocate many a range of vlans on an link
• 4. Allocate and deallocate a range of vlans on an link

@Alopalao, after your current tasks if you could also help out with this one, the idea is to stress test it on 2023.2+ and confirm there's no Interface.available_tags[vlan] being leaked. I realized some of stress test has been done on #428, but let's go over these ones here again. It turns out that in prod, there has been some leaked vlans on prior versions, but it was mostly due to other known issues, but let's make sure that with vlan ranges we get to stress test it one more time, just so if there's something to surface it might show up, although it looks very solid, but let's confirm it in practice again.

[Alopalao]

Through the testing I have done, I have not found any problems with the locks that secure the usage of VLANs for NNIs and UNIs. The only errors I have noticed were due to error handling with flows and consistency check EVC restauration.

My testing consisted in multiple threads (~7):

• Creating and trying to create duplicated EVCs.
• Creating and randomly deleting random generated VLANs
• Creating and randomly deleting random generated VLANs. Additionally randomly restoring deleted VLANs.

All the testing have been done with single and ranged VLANS.

[viniarck]

Good to know, Aldo. Let's close this issue here since the original goal was achieved.