V to W upgrades brake due to python_venv_build serial checks

[Bjoern]

During my upgrade from V to W I encounter the following issue which either forces me to limit the infra node upgrade to one by one or I set the override venv_wheel_build_skip_check to disable it.

When I look at certain playbooks like utility-install or barbican for example, these don't use any serial condition resulting in a parallel upgrade as ansible_play_batch matches all delegated hosts of a task.

Adding a serial condition is probably an option but I feel the condition should be separating between compute and control plane upgrades. I would also assume that everyone who encounters the issue will disable it anyway putting this condition in question in the first place so we should decided what to do long term

Error

```
TASK [python_venv_build : Fail if wheels are not built for multiple hosts] *********************************************************************************************************************************************************************
fatal: [controller3]: FAILED! => {"changed": false, "msg": "You are not building wheels while running role against multiple hosts. This might result in DOS-ing OpenDev infrustructure servers. In order to proceed, please ensure that y
ou have repo servers for selected OS version and architecture. If you want to avoid building wheel on purpose, ensure that you run playbook in serial manner. In case of causing unreasonable load on the opendev.org git servers, your access m
ay be blocked to protect other users and the OpenDev CI infrastructure which are reliant on this service. Found venv_build_targets: {'20.04': {'x86_64': 'controller3'}}"}
```

[Dmitriy Rabotyagov (noonedeadpunk)]

Hi,

Based on the error you've supplied, issue is not in serial but that wheels are not being build. This means, that for each virtualenv in your environemnt that is being upgraded packages are being cloned independently from external resources, rather then being built once and then installed from repo container, which won't require independant external clonning for each node.

The the issue that should be investigated instead, is why wheels are not build for your environment as they supposed to. From the output it seems, that build target is found properly.

I assume you're having metal deployment? On Wallaby we have obsolete/weird logic that might not work for metal deployments, where we assume that repo host can't be the same as build host.

So for metal deployments before Yoga I'd suggest defining following in user_variables.yml to eliminate that logic drawback:

venv_wheel_build_enable: true

Since Yoga we have changed logic quite dramatically, but it can't be backported due to complexity.