fence_vmware_soap has no connection timeout, results in filling up tmp directory

The resource agent `fence_vmware_soap` has no connection timeout when creating a suds `Client` and does not respect any of the `--power-timeout` `--shell-timeout` `--login-timeout` options.

This is important because when running under pacemaker and trying to contact a server that doesn't respond, the script will run until pacemaker forcibly kills it, which leaks the created python `tmpdir` (and will eventually fill up the disk).

It can be easily observed by setting up fence_vmware_soap in pacemaker and then blocking the server in iptables:
```
pcs stonith create stonith_vmware fence_vmware_soap ipaddr="${esxi_host_ip}" ....
iptables -A INPUT -j DROP -s "${esxi_host_ip}"
```
And the `/tmp/` directory will slowly start filling up.

Start in the fence_vmware_soap resource agent and inspect where the suds Client is created, then trace how --power-timeout, --shell-timeout, and --login-timeout are handled. Reproduce the blocked-server case described with iptables and check the temporary-directory lifecycle. Done means connection attempts honor the relevant timeout and do not leave temporary directories behind.

Written by the indexing model from the issue text.