Description of the issue/feature this PR addresses: In the Bills Dashboard (Accessible by clicking on the vendor Bill Journal and removing the filter for example), for a lot of different entries the payment status is indicated as "Not paid" even though no payment is expected for those entries. Moreover, this status will not change even though a payment is registered, which is counter intuitive. (Example: a payment is registered -> a payment line PBNK will have the status "Not paid")

Desired behavior after PR is merged: The payment status is visible if the entry is "Posted" AND the entry belongs to one of those type:  [Bill (BILL), Refund (RBILL), Purchase Receipt (BILL), Invoice (INV), Credit notes (RINV), Sale Receipt (INV)]. 
If the entry does not meet those criteria, make the payment status invisible. I also kept the previous visibility criteria which stated that the payment status is not visible if the payment state is set to 'Invoicing App Legacy".

task id : 3091141


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The main goal is to reduce the processing time
it takes for views to be validated during installation.

In order to mimic the behavior of the view creations during installation, and to analyze the performance, I used the below code in the shell:

```py
env.cr.rollback()
domain = [('model', '=', 'res.config.settings')]
views = self.env['ir.ui.view'].search_read(domain, [
    'id', 'active', 'arch', 'inherit_id', 'key', 'mode', 'model', 'priority', 'type', 'xml_id'
], order="id ASC")
for view in views:
    if view['inherit_id']:
        view['inherit_id'] = self.env['ir.ui.view'].browse(view['inherit_id'][0]).xml_id

self.env['ir.ui.view'].browse(reversed([view['id'] for view in views])).unlink()
with odoo.tools.profiler.Profiler():
    for view in views:
        new_view = self.env['ir.ui.view'].create({
            key: self.env.ref(value).id if key in ['inherit_id'] and value else value
            for key, value in view.items()
            if key not in ['id', 'xml_id']
        })
        if view['xml_id']:
            module, name = view['xml_id'].split('.')
            self.env['ir.model.data'].create({
                'module': module,
                'name': name,
                'model': 'ir.ui.view',
                'res_id': new_view.id,
            })
env.cr.rollback()
```

Using the above, and analyzing the speedscope profile, we can see the lines

```py
action = self.env['ir.actions.actions'].browse(action_id).exists()
```
from `_validate_tag_button`, and

```py
if not self.env['ir.model.data']._xmlid_to_res_id(group.strip(), raise_if_not_found=False):
```
from `_validate_attrs`

take a significant time.

Batching the actions and groups existence
(as recommended as further improvement in the comment which is deleted by this revision), as well as a more efficient algorithm for `_get_node_groups`, reduce the processing time of the views validation.

On my computer, the above code creating all the views for `res.config.settings`, which is an extreme case because the view has 100 inherited views, allows to reduce the validation processing time from 9.42s to 8.18s.
Specifically, `_validate_view` goes from 3.24s to 1.18s, which is about a 270% speed improvement for that method alone.

#### Speedscope profile screenshots:
##### Before
![before](https://user-images.githubusercontent.com/5822488/207062386-44a0c11f-c776-4a1c-a52a-fa6cf57b38bf.png)

##### After
![after](https://user-images.githubusercontent.com/5822488/207062406-9ccbeade-0676-4ec8-8dca-d22daaaf3db2.png)


Regarding the algorithm for `_get_node_groups` itself:
```py
In [0]: %timeit tuple(tuple(n.get('groups').split(',')) for n in node.xpath('ancestor-or-self::*[@groups]'))
10.1 µs ± 91 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)

In [1]: %timeit groups = [tuple(n.get('groups').split(',')) for n in chain([node], node.iterancestors()) if n.get('groups')];groups.reverse();tuple(groups)
3.46 µs ± 29.2 ns per loop (mean ± std. dev. of 7 runs, 100000 loops each)
```