[python-experimental] consolidates endpoints into paths module

Created by: spacether

[python-experimental] consolidates endpoints into paths module

If master branch had an endpoint tagged with multiple tags, that identical endpoint was written multiple times That is not ideal This refactor produces one module for each path and underneath that module, there is a module for each operation post/put/patch etc. This makes the generated code structure similar to the structure of the spec, so endpoint definitions can be defined once and imported elsewhere where needed, like in tagged apis. This will reduce the amount of code that is generated when multiple tags are used on the same endpoint

Breaking change

• removes the api module, use apis.tags.tag_name.py instead

Reason for the change: the api module is no longer needed, and its functionality has been replaced with apis.tags.some_tag modules. This change reduces the amount of code because those apis are now imported from the new paths module. Code is reduced because each endpoint is only defined once in the paths module, even if has multiple tags. Note: breaking changes are allowed using experimental status generators at any time please make sure to peg your openapi-generator version to avoid accidentally using a version with breaking changes

Updates:

• qty lines reduced by ~70,000 net
• coverage updated to 78% for the python-experimental v3.03 test spec client auto generated tests
• adds paths module with endpoints defined in it
• removes the api module, use apis.tags.tag_name.py instead
• adds tag_to_api and path_to_api in the apis module to allow developers to go from a tag or path to an api defined on that resource
• there is now one test file per endpoint in the unit_test_api

Examples of api access by path or tag

Note: using path_to_api or tag_to_api will take a bit of time to load for large apis. If you want quicker load times, then just import the required api directly.

# get an api by a path
from package.paths import PathValues
from package.apis.path_to_api import path_to_api
path_enum = PathValues("some/path")
api = path_to_api[path_enum]
# api has .post/put/patch etc methods on it

# get an api by a tag
from package.apis.tags import TagValues
from package.apis.tag_to_api import tag_to_api
tag_enum = TagValues("someTag")
api = tag_to_api[tag_enum]
# api has .operation_id etc methods on it

TODO

1. [DONE] produce the paths folder with endpoints in it
2. [DONE] produce the paths folder with amalgamation classes in it and move it into the apis module
3. [DONE] generate an path_to_api python file in apis
4. [DONE] move tags into a tags submodule
5. [DONE] fix the apis.tags.some_tag OperationId imports
6. [DONE] generate tag enums in apis.tags.__init__
7. [DONE] generate tag_to_api python file in apis
8. [DONE] update api tests to have the structure test.test_paths.test_path.test_post or test.test_apis.test_path.test_post
9. [DONE] fix the tests:add init files, move the base api test class into the test_paths module
10. [DONE] update python-experimental tests to use apis rather than api
11. [DONE] one method for each api test case
12. [DONE] update the docs to use from apis.tags.tag import TagApi

PR checklist

• Read the contribution guidelines.
• Pull Request title clearly describes the work in the pull request and Pull Request description provides details about how to validate the work. Missing information here may result in delayed response from the community.
• Run the following to build the project and update samples:

  ./mvnw clean package 
  ./bin/generate-samples.sh
  ./bin/utils/export_docs_generators.sh

  Commit all changed files. This is important, as CI jobs will verify all generator outputs of your HEAD commit as it would merge with master. These must match the expectations made by your contribution. You may regenerate an individual generator by passing the relevant config(s) as an argument to the script, for example ./bin/generate-samples.sh bin/configs/java*. For Windows users, please run the script in Git BASH.
• File the PR against the correct branch: master (6.1.0) (minor release - breaking changes with fallbacks), 7.0.x (breaking changes without fallbacks)
• If your PR is targeting a particular programming language, @mention the technical committee members, so they are more likely to review the pull request.