MTU is not taken into consideration when adding random padding

[otternetwork]

When adding random padding, it would be nice to watch out the MTU to not exceed the maximum UDP packet length to avoid fragmentation. If the packet is already as large as possible, then add nothing at all.

Let's say we have an interface with MTU 1500. Then the maximum UDP payload will be 1472.

1. If payload is 1472 then we cannot add random padding (we cannot add the padding length either since it would require extra 1 byte that we don't have room for). This case will be tricky for the receiving side to detect. Any suggestions?
2. If payload is <1472 then the maximum padding length will be 1471-len (plus 1 byte padding length). This fix requires change on the sender side only without loosing backward compatibility.

If you don't want to deal with getting MTU of the outgoing interface, it would be safe to turn the padding off completely somewhere after ~1200 bytes.

Sender:

1. if len>=1200 then don't add padding
2. if len<1199 then pad the packet up to maximum 1199 bytes

Receiver:

1. if len>=1200 consider we have no padding and no padding length byte
2. if len<1200 consider we do have the padding length byte

PS. This issue was likely affected by this problem: https://github.com/infinet/xt_wgobfs/issues/3

[infinet]

It is better to load iptables rules before bring up wireguard interface. Wireguard has an option to specify its MTU. If limit WG interface MTU to a safe number, for example 1200, then after padding, the overall UDP packet is still smaller than the link MTU.