Ifcfg: Fix file writing races

On a fast enough computer, it could very well happen that we'd do:
    open('foo', 'w').write('moo')
    execCmd(['cat', 'foo'])

And that the content that 'cat' would show for foo would not be 'moo'
but whatever was there before the write, due to the file closing
happening at a non deterministic point of time.

How was this horribly edgy case unearthed? Good question!

Let's say we have a bond0 with slaves em2 and em1. We are in the
process of removing the bond completely.

removeNic basically stripes the nic ifcfg file of everything except
the hwaddr, device type, etc. So, if there was previously for nic em1
MASTER=bond0

after removeNic, there is an ifup of em1 (to leave the link state up)
that would still see bond0 as master. That in turn would make
initscripts trigger ifup of bond0, but that ifcfg file no longer
exists, ifup fails, raises an exception, and the whole removal is
rolled back.

Needless to say, this was unfindable with the debugger, as the file
close would be fast enough due to the debugger slowing down operation.

Change-Id: I6aabfbba44f1250f305ef6ec06f715e4782c4d1b
Signed-off-by: Antoni S. Puimedon <asegurap@redhat.com>
Reviewed-on: http://gerrit.ovirt.org/20050
Reviewed-by: Assaf Muller <amuller@redhat.com>
Reviewed-by: Dan Kenigsberg <danken@redhat.com>