fix u2o policy route generate too many flow tables cause oom

[changluyi]

• Make sure you have followed Kube-OVN Code Style.

What type of this PR

Examples of user facing changes:

• Features
• Bug fixes
• Docs
• Tests

The steps to reproduce are as follows：

1. underlay subnet enable u2o,( my default subnet is underlay)
2. edit deployment kube-ovn-controller replicas to 0
3. using this command to add some address to this address set manually and add more addresses
   kubectl ko nbctl add Address_Set ovn.default.u2o_exclude_ip.ip4 addresses "4.4.4.4"

Then you will find that the number of openflow flow tables is increasing rapidly using command in your ovs-ovn pod：
ovs-ofctl dump-flows br-int | grep 31000 | wc -l

Which issue(s) this PR fixes:

Fixes

when turn on the u2o switch, the policy route below will cause oom, when addresses in the address set are more than 8 , or the underlay subnet's mask length is big, it will cause the ovs to generate many OpenFlow tables.

The reason is that when ovn generates the flow table, it divides dst 192.168.0.0/16 into addresses to generate the openflow flow table. And it seems that the same address may form various rules with different masks.

WHAT

🤖 Generated by Copilot at fae7792

Simplify and lower the priority of the policy route for underlay to overlay traffic. Define and use a constant for the priority value in subnet.go and underlay.go. Update the test case in underlay.go to match the new policy route.

🤖 Generated by Copilot at fae7792

We're sailing on the overlay subnet, me hearties
We need a policy route to get us there
We'll simplify the match and lower the priority
And use a constant to make it fair

HOW

🤖 Generated by Copilot at fae7792

• Simplify the match condition and update the priority of the policy route that allows traffic from the underlay subnet to the overlay subnet (link, link, link, link, link)