veth0 weirdness

Discovered an anomoly while exploring using veth for some testing scenarios.

The following will always fail with EEXIST:
# ip li add dev veth0 type veth
RTNETLINK answers: File exists

The reason is that name for the peer is always created first via:
"veth%d" and that will return "veth0". Then when the requested device
is created it will conflict with itself.

Not a big problem, but may confuse users. Fixing it would involve some more
complex transactional logic to create the primary device first then
create the peer which could get messy and likely buggy on first versions
for all the cases.