Major sdk update

[Arondondon]

Update includes the following:

1. Removing CLI dependencies. Now SDK does not depend on CLI in any way and works separately. In addition, as a result of this, the logic of some methods in SDK has changed, as well as the project structure - the client_lib_generator, utils, ipfs_utils, config and service_metadata modules have been added.
2. Documentation. Complete technical documentation has been written (project directory "docs"). The README.md file has also been updated, now it contains a complete description of all the functionality of the Python SDK.
3. Examples. There are two examples of using Python SDK to create custom applications. Among them, one is small - a calculator based on the SIngularityNET platform service, and the second is a full-fledged console application that uses all the functionality of the SDK. For both examples, .md files with tutorials on creating these examples are written. (Project directory "examples").

[kiruxaspb]

Docs approved

[kiruxaspb]

Approved updated docs

[kiruxaspb]

Update docs for config update

[kiruxaspb]

@Necr0x0Der Could your please review this one PR?

Here we have updated the moment and now private keys are not stored in idenitity.

[Necr0x0Der]

@Necr0x0Der Could your please review this one PR?

Here we have updated the moment and now private keys are not stored in idenitity.

Hmmm... The PR is quite large for a comprehensive review for me atm. What I see is that a lot of code was moved from cli to sdk, which is good. Config has become more compact and private keys are not stored, which are also good. This can be easily adopted in sdk in metta.
I'm not sure why there are so many proto files and pre-build pb2_grpc files in resources? Do they describe a standard API for daemons and are not stored on ipfs?
In any case, I don't see issues with changes on the client side from a quick glance.

[kiruxaspb]

I'm not sure why there are so many proto files and pre-build pb2_grpc files in resources? Do they describe a standard API for daemons and are not stored on ipfs? In any case, I don't see issues with changes on the client side from a quick glance.

Thank you for review, @Necr0x0Der.

Yes, proto files stored in resources describe fixed API for daemons and IPFS downloads checks.
These are service protos, and I think it's more efficient to store them immediately in the package than to add additional downloading from IPFS, compiling and custom importing of these proto files in snet.sdk codebase.

We will add the issue of moving service protos to decentralized storage in our backlog.

[DaddyWesker]

Initializes the m dict with empty of default values.

Probably there should be 'or' not 'of'? It is in https://github.com/Arondondon/snet-sdk-python/blob/development/docs/metadata_provider/service_metadata.md file

If the endpoint is not valid of if the group does not exist

Same here?

[DaddyWesker]

Code from calculator example.

def parse_expression(expression):
    elements = list(expression.split())
    if len(elements) != 3:
        raise Exception(f"Invalid expression '{expression}'. Three items required.")

    a = int(elements[0])
    b = int(elements[2])
    if elements[1] not in ["+", "-", "*", "/"]:
        raise Exception(f"Invalid expression '{expression}'. Operation must be '+' or '-' or '*' or '/'")
    elif not isinstance(a, (float, int)) or not isinstance(b, (float, int)):
        raise Exception(f"Invalid expression '{expression}'. Operands must be integers or floating point numbers.")
    op = elements[1]

    return a, b, op

Maybe I'm wrong, but elif not isinstance(a, (float, int)) or not isinstance(b, (float, int)): is useless currently since:

 a = int(elements[0])
 b = int(elements[2])

So, a and b will always be ints. Moreover, if user inputs float number it will be converted to int. Or I am missing something?

[Arondondon]

Thank you for review, @DaddyWesker.
You were right about the issues in service_metadata.md and calculator.py. Currently, they have been fixed.

[kiruxaspb]

Approved