Typing infrastructure improvements

[parfeniukink]

1. Static type checkers, based on pyright won't work correctly due to the hierarchy of the exported classes and modules (examples from LSP / VSCode pylance presented on screenshots). It means, that for instance smart tools like mypy will definitelly work correctly, but real-time type checkers will distruct developers all the time.
2. The base classes, or let's say what do you call Generic classes are placed on the same level from the hierarchy perspective which means that it is quite hard to use. According to some sorts of best-practices it is recommended having something like the infrastructure layer for the project that is in development.
   2.1. In this PR you'll find the infrastructure layer that encapsulates all the shared logic for the whole application and make it linear from modules importing perspective (now, there is no imports on the same level)
3. All the if TYPE_CHECKING: lines are removed due to it's unnecessary. Basically this line might be useful if you have some architecture issues (circular imports) in your code but seems there is no reason to overcomplicate the project with additional if statement in all concrete implementations. Even thought if we decide having them in the project I would recommend using from __future__ import annotations over the if TYPE_CHECKING:
4. All the docstrings are unified
5. Imports are simplified with __all__. Since the __all__ could be used to control wild imports in Python this is definitely a good way to go with in my opinion. In the old version of the code the controll of the import is on the __init__.py which make developers to think about a couple of places to export their modules. With current approach you control your concrete SSO implementation in your single file which make the code more robust from changes perspective. Like, all the names that are allowed to be imported from this module are defined in this module itself. And, the way to import this module is defined on the level above (on the package level).

So basically this is the result of the typings improvements:

[codecov]

Codecov Report

❌ Patch coverage is 92.20779% with 6 lines in your changes missing coverage. Please review.
✅ Project coverage is 91.07%. Comparing base (cb86159) to head (be1555c).
⚠️ Report is 95 commits behind head on master.

Files with missing lines	Patch %	Lines
fastapi_sso/sso/google.py	50.00%	3 Missing ⚠️
fastapi_sso/sso/spotify.py	75.00%	2 Missing ⚠️
fastapi_sso/sso/fitbit.py	80.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #120      +/-   ##
==========================================
+ Coverage   88.16%   91.07%   +2.90%     
==========================================
  Files          14       16       +2     
  Lines         338      336       -2     
==========================================
+ Hits          298      306       +8     
+ Misses         40       30      -10     

Files with missing lines	Coverage Δ
fastapi_sso/__init__.py	100.00% <100.00%> (ø)
fastapi_sso/infrastructure/__init__.py	100.00% <100.00%> (ø)
fastapi_sso/infrastructure/factories/__init__.py	100.00% <100.00%> (ø)
fastapi_sso/infrastructure/factories/provider.py	100.00% <100.00%> (ø)
fastapi_sso/infrastructure/openid.py	100.00% <100.00%> (ø)
fastapi_sso/sso/__init__.py	100.00% <100.00%> (ø)
fastapi_sso/sso/facebook.py	92.30% <100.00%> (+6.59%)	⬆️
fastapi_sso/sso/github.py	56.00% <100.00%> (+2.15%)	⬆️
fastapi_sso/sso/gitlab.py	92.30% <100.00%> (+6.59%)	⬆️
fastapi_sso/sso/kakao.py	92.30% <100.00%> (+6.59%)	⬆️
... and 6 more

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[tomasvotava]

Hi @parfeniukink, thanks! From the first read I'd say it's very nice, although I am not a huge fan of the infrastructure subpackage name. I'll have another look, preferably tomorrow and either approve or propose some actual changes. Good job!

[parfeniukink]

Hi @parfeniukink, thanks! From the first read I'd say it's very nice, although I am not a huge fan of the infrastructure subpackage name. I'll have another look, preferably tomorrow and either approve or propose some actual changes. Good job!

Well, yeah. I agree with the infrastructure naming, but anyway, I just chose the default naming for the shared module right from the DDD approach since there are no other approaches discussed/declared yet. And I hope you agree that at least any of the familiar design approaches in the dev community is better than no one :)

btw, I think that infrastructure layer is kind of a good naming bud not for the 3-rd party package, like fastapi-sso which must be a part of the infrastructure layer in other applications 😄