Without security group rule for port 67 in egress, VMs may not be able to get an IP from DHCP

Reference comments on bug 1790900 that also explain its undesired side effect:

https://bugs.launchpad.net/networking-ovn/+bug/1790900/comments/7

https://bugs.launchpad.net/networking-ovn/+bug/1790900/comments/12

We have a working fix for this issue here [1]. However, we are no longer convinced that
the code complexity introduced by the change justifies its benefits. Reasons for that are:

1) More places for a bug to live;
2) Default egress rules work just fine to give VMs access to dhcp and metadata; so this is
   an unnecessary burden in memory and configuration for most use cases;
3) If the operator wants total control over egress rules, implicitly adding SGR behind the
   scenes is exactly what we should _not_ do.

Lastly, just a note that this is a slight departure from the default behavior that one gets
when using ml2/ovs. Even though mls/ovs adds no 'implicit' rules for allowing vms to reach
metadata, it does add the dhcpv4 rules. When using ml2/ovn, operators will need to do add the
rules on his/her own. It would look along these lines:

   # Allow VM to contact dhcp server (ipv4)
   openstack security group rule create --egress --ethertype IPv4 --protocol udp --dst-port 67 ${SEC_GROUP_ID}
   # Allow VM to contact metadata server (ipv4)
   openstack security group rule create --egress --ethertype IPv4 --protocol tcp --remote-ip 169.254.169.254 ${SEC_GROUP_ID}

   # Allow VM to contact dhcp server (ipv6, non-slaac). Be aware that the remote-ip may vary depending on your use case!
   openstack security group rule create --egress --ethertype IPv6 --protocol udp --dst-port 547 --remote-ip ff02::1:2 ${SEC_GROUP_ID}
   # Allow VM to contact metadata server (ipv6)
   openstack security group rule create --egress --ethertype IPv6 --protocol tcp --remote-ip fe80::a9fe:a9fe ${SEC_GROUP_ID}

[1]: https://review.opendev.org/#/c/733033/