Fix cacert.pem extraction from zip.

Fix cacert.pem extraction from zip.

Two issues addressed here:
 * Looks like something is nuking /tmp/* on bots, and extracted
   cacert.pem with it, which causes https requests to fail. Extract
   cert bundle to ./ instead.
 * utils/oauth.py is broken when used from inside zip archive.

R=maruel@chromium.org
BUG=

Committed: https://code.google.com/p/swarming/source/detail?repo=client&r=e7d8b98

[vadimsh, 2014-08-26 23:05:30]

ptal

https://codereview.appspot.com/131330044/diff/1/utils/net.py
File utils/net.py (left):

https://codereview.appspot.com/131330044/diff/1/utils/net.py#oldcode288
utils/net.py:288: def get_cacerts_bundle():
This function is now used from both utils/oauth.py and utils/net.py. And
utils/oauth.py can't import utils/net.py (circular dependency). So moved to
utils/tools.py instead (since putting it in utils/oauth.py is odd).

https://codereview.appspot.com/131330044/diff/1/utils/tools.py
File utils/tools.py (right):

https://codereview.appspot.com/131330044/diff/1/utils/tools.py#newcode204
utils/tools.py:204: if _ca_certs is not None and os.path.exists(_ca_certs):
ha, I think I know why it broke only now. 

Since https://codereview.appspot.com/134740043 (that was deployed with your
version today), utils/net.py is reusing connections again, and
get_cacerts_bundle() is now called only _once_ when creating first HttpService
object.

Before this fix, new HttpService object was created for each request, and
get_cacerts_bundle() was called for each request too, and
os.path.exists(_ca_certs) check here detected missing file and recreated it.

[M-A, 2014-08-26 23:13:51]

lgtm

https://codereview.appspot.com/131330044/diff/1/utils/tools.py
File utils/tools.py (right):

https://codereview.appspot.com/131330044/diff/1/utils/tools.py#newcode196
utils/tools.py:196: Python SSL needs a real file on disk, so if code is running
from a zip
Python's OpenSSL

https://codereview.appspot.com/131330044/diff/1/utils/tools.py#newcode200
utils/tools.py:200: from third_party import requests
Why late import?

https://codereview.appspot.com/131330044/diff/1/utils/zip_package.py
File utils/zip_package.py (right):

https://codereview.appspot.com/131330044/diff/1/utils/zip_package.py#newcode271
utils/zip_package.py:271: with os.fdopen(fd, 'w') as stream:
Don't you still have to os.close() it afterward or fdopen().close() closes the
handle? The doc is unclear about it.

[vadimsh, 2014-08-26 23:25:40]

https://codereview.appspot.com/131330044/diff/1/utils/tools.py
File utils/tools.py (right):

https://codereview.appspot.com/131330044/diff/1/utils/tools.py#newcode196
utils/tools.py:196: Python SSL needs a real file on disk, so if code is running
from a zip
On 2014/08/26 23:13:50, M-A wrote:
> Python's OpenSSL

To be precise it's _ssl.so module, that links to openssl dyn lib. Python's
OpenSSL is easy to confuse by PyOpenSSL. Reformulated this a bit.

https://codereview.appspot.com/131330044/diff/1/utils/tools.py#newcode200
utils/tools.py:200: from third_party import requests
On 2014/08/26 23:13:50, M-A wrote:
> Why late import?
I don't know... Fixed.

https://codereview.appspot.com/131330044/diff/1/utils/zip_package.py
File utils/zip_package.py (right):

https://codereview.appspot.com/131330044/diff/1/utils/zip_package.py#newcode271
utils/zip_package.py:271: with os.fdopen(fd, 'w') as stream:
On 2014/08/26 23:13:51, M-A wrote:
> Don't you still have to os.close() it afterward or fdopen().close() closes the
> handle? The doc is unclear about it.

Trying to call os.close(fd) here causes OSError: [Errno 9] Bad file descriptor.
So I think fdopen().close() closes FD too.

[vadimsh, 2014-08-26 23:26:51]

Committed patchset #2 manually as e7d8b98 (presubmit successful).