Drop usage of auto generated EduSharing client code

[MRuecklCC]

Currently, the es_connector.py file makes use of both:

• the requests package to issue requests e.g. to update thumbnail or fulltext (e.g. here)
• as well as the client code in the edu_sharing_client directory which was once autogenerated in 674bb93 (not modified since then and likely partially outdated).

I propose to:

• fully remove the edu_sharing_client directory
• replace the following usages of the autogenerated code with calls directly using requests library.
  • EduSharing.iamApi.create_group
  • EduSharing.iamApi.search_groups
  • EduSharing.iamApi.get_group
  • EduSharing.bulkApi.find
  • EduSharing.bulkApi.sync
  • EduSharing.nodeApi.set_permission

Alternatively, we can implement a extremly simplified version of the EduSharing client code that provides only the hand full of methods needed and separates the authentication/authorisation/validation out of the EduSharing class.

[MRuecklCC]

After some discussion with @torsten-simon and @Criamos we came up with the preferred idea of moving the autgenerated code to a dedicated python package which gets published at pypi. Then we can remove the autogenerated code from here.

Also the current occurrences where we use request module should then be replaced with using the generated code if possible.

Plan would be to use https://openapi-generator.tech/docs/generators/python (as before).

[torsten-simon]

@MRuecklCC may this branch helps:
https://github.com/openeduhub/oeh-search-etl/tree/api-codegen-migration#regenerating-openapi-files

[MRuecklCC]

I played around a little with the openapi-tools generator:

• when using the python generator, we won't get any typehints in the generated client code.
• when using the python-experimental generator the generated code has import errors (it doesn't handle naming of the API version consitently)
• there is also a python based generator: https://github.com/openapi-generators/openapi-python-client which would be nice to use (because it seems to focus more on the quality of the generated code, having typhints, and using new python features). However that tool generates a lot of errors when processing the open API spec of the edusharing service.

The current state of what I got so far is available in https://github.com/MRuecklCC/edu-sharing-client-python

As a next step, I would try to report/fix the issue of the python-experimental generator.

[MRuecklCC]

After looking at the source code of both https://github.com/openapi-generators/openapi-python-client and https://github.com/OpenAPITools/openapi-generator I decided that I like the first one a lot more...

For reference I also created the following issue: OpenAPITools/openapi-generator#12986

[spacether]

in the future, if you want to reconsider using the python-experimental generator. I fixed you filed issue in this PR. So your spec now works with our generator.