Description of problem:

When creating an EgressFirewall with a number of `Allow` rules and a last `Deny` catch-all rule, the drop ACL in the nbdb is created with a priority higher than some of the allow rules that are above it. Drop ACL should be the least priority one if it is the latest rule in the egress firewall.

The visible effect is that some allowed destinations are unreachable.

Re-creating the egress firewall can fix or trigger the issue to different endpoints at random. I didn't check the details before and after doing so, but given what I found in the nbdb when a single failure was happening, it is likely  to mean that the priority "distribution" is kind of random.

Version-Release number of selected component (if applicable):

4.9.29

How reproducible:

At concrete environment, always. Random behavior.

Steps to Reproduce:
1. Create or re-create EgressFirewall
2.
3.

Actual results:

ACLs with allow rules have lower priority than the drop rule from LATEST `Deny` rule.

Expected results:

Drop ACL to have least priority so it doesn't take precedence over the allow ones, because the `Deny` rule that created it is the last one.
Additional info:

Additional Info:

Relevant attachments and data will be expanded in comments.

Apart from that, I did some quick source code inspection. If I got everything correctly, when reading the egress firewall rules, those rules get an "id" based on the position at `Spec.Egress` array on the EgressFirewall object[1]. Then, that "id" is substracted to a start priority[2], so that the higher that "id" is, the lower the priority. Assuming that order is preserved properly, I honestly don't understand how this can happen, so I must be missing something.


[1] - https://github.com/openshift/ovn-kubernetes/blob/e9e0debd04b0124ba17c18483a93497efbae19be/go-controller/pkg/ovn/egressfirewall.go#L336
[2] - https://github.com/openshift/ovn-kubernetes/blob/e9e0debd04b0124ba17c18483a93497efbae19be/go-controller/pkg/ovn/egressfirewall.go#L446