Tasks handling nova-status upgrade check are too restrictive

When upgrading from Rocky to Stein with active Ironic nodes, `nova-status upgrade check` fails with this warning:

```
+---------------------------------------------------------------------+
| Check: Resource Providers |
| Result: Warning |
| Details: There are 1 compute resource providers and 4 compute nodes |
| in the deployment. Ideally the number of compute resource |
| providers should equal the number of enabled compute nodes |
| otherwise the cloud may be underutilized. See |
| https://docs.openstack.org/nova/latest/user/placement.html |
| for more details. |
+---------------------------------------------------------------------+
```
This command returns code 1, which causes the "Check nova upgrade status" task in `ansible/roles/nova/tasks/upgrade.yml` to fail with "non-zero return code".
Here is the relevant part of this file:

```
- name: Check nova upgrade status
  become: true
  command: docker exec -t nova_api nova-status upgrade check
  register: nova_upgrade_check_stdout
  when: inventory_hostname == groups['nova-api'][0]

- name: Upgrade status check result
  fail:
    msg:
      - "There was an upgrade status check warning or failure!"
      - "See the detail at https://docs.openstack.org/nova/latest/cli/nova-status.html#nova-status-checks"
  vars:
    first_nova_api_host: "{{ groups['nova-api'][0] }}"
  when: hostvars[first_nova_api_host]['nova_upgrade_check_stdout']['rc'] != 0
```

Now, there are two problems here. Firstly, on https://docs.openstack.org/nova/stein/cli/nova-status.html#upgrade only codes 2 and 255 are mentioned as fatal errors that should stop the process with code 1 being just a warning. Secondly, it doesn't make sense to run the next task (the "Upgrade status check result") to check the code returned by the nova-status command, because the first task will always fail if the command returns anything different than code 0.

My opinion is we should tell Ansible to ignore errors from the first task and then add more conditions to handle the returned code. It may also be worth adding a parameter controlling how strict the check should be, so if this parameter is set to true, only code 0 is allowed, otherwise both code 0 and 1 are acceptable.