Well, _MARKER is used to backward compatibility and to raise an error
which if the networkcache server is not consistenty.

Without _MARKER there is not way to make these conditions.

A simple object of NetworkcacheClient class is already instantiated by
setUp method.

Following the previous commit, _MARKER is not required anymore.

Well, before this change the signature_certificate_file_list worked
only with filesystem paths.
 - i.e ['/home/user/public.pem']

Now it is possible to define urls as well.
 - i.e ['http://example.com/public.pem']

The url content will be downloaded to a temporary file before the
verification and automatically removed after.

The filesystem paths has higher priority than url, it is checked first.
If it does not find any valid certificate, then it will try
to download the certificates from the url provided.

This is the first version has only basic tests.

The new test class aims to test the behavior of NetworkcacheClient
class. And it is forbidden to change any behavior of
NetworkcacheClient without writting/editing the tests.

NOTE: still WIP...

Now the mixin class is able to create the files which are required to
add the signature, it will be usefull for TestNetworkcacheClient.

Well, the LibNetworkCacheMixin has been created to avoid any kind of
code duplication inside of this test suite.

This mixin class is gonna be used by TestNetworkCacheClient.

Some variables have been renamed for a better understanding, but the
behavior of the code still the same.

It is not recommanded to use httplib directly, we should better
use urllib2, then this library will use httplib. This solve
issues with libnetworkcache when we try to use it behind an
http proxy.

Actually, the user can configure the buildout.cfg and set multiples
certificates files.

It means that libnetworkcache must be able to check if the signature
which comes from shadir is trustable or not, based on these certificates.

A given signature can not appear twice in the same directory-key, if it
happens a DiretoryNotFound error must be raised.

Renamed signature_public_file to signature_certificate_file, because the
name is cleaner once the content of the file is a X509 certificate
file. It is also known as Public Key Certificate.

Renamed signature_private_file to signature_private_key_file, because
the is is cleaner once the content of the file is a private RSA key.

Actually, the slapos.libnetworkcache has new dependeincies because
M2Cryto is required to handle the signatures inside NetworkcacheClient class
and the argparse is required by signature.py script.

Now it is possible to create the signature files easily using the
command generate-signature-key with the correct arguments.

The command generate-signature-key works without any argument as well.

To check the arguments you must run with the parameter --help/-h.

It'll generate two file, one is a private key and the other is a
X509 certificate file.

Those files must be used by networkcache to play with signature.

The private key is required to sign the message before uploading it to
shadir. And the certification file is required to verify the signature.

M2Crypto is required to create the signature string and verify if it is
valid or not.

The signature private file is not required to verify the signature it is
only used to create the signature string.

The signature verification requires only the public file...

We should not send the signature in the property dict. Otherwise,
the validation of json schema will fail.

Also fix formatting a bit.

It should return the file descriptor instead of file content as string.

This implementation does not consume RAM Memory, so it is safer to
download big files.

When you call file_descriptor.close, it will remove the file from tmp
folder automatically.

There is no need to read and store downloaded file. Returning the location is
good enough.

Rest of file requires hexdigested file.

There is no need to read whole file into memory on library level. So calculate
sum in chunks and give request method file descriptor.

Indeed, some day documentation shall be written, as soon as API will be defined.