feat: Syncers for synchable Id-Providers about casdoor

[casbin-bot]

@seriouszyx @ComradeProgrammer @Resulte

[hsluoyz]

@leoncamel sounds good. Can you split the syncers to different issues? One issue for one syncer. Because one syncer itself is a big code change itself

[leoncamel]

@hsluoyz Sure, I will submit idP related syncer as new issue. This issue remains as a umbrella issue to discuss general concepts.

[leoncamel]

I add split it into #2624, #2625.

Currently, we have many Id-Providers, but not all of them are syncable/sychronisable. Some Id-Provider support additional APIs for Listing Users. Further more, some Id-Provider provide incremental APIs, like Microsoft's Graph API, which make its Syncer become a Stateful Syncer(since it need store last checkpoint position).

I just did a quick survey about these Id-Providers:

Provider Name	Syncable	Incremental Syncable
ADFS
AliPay
AzureADB2C
Baidu
Custom
Casdoor
DingTalk	Yes
Douyin
Facebook
Gitee
Github
Gitlab	Yes
Google
Goth
Infoflow Internal
Inforflow 3rd-party
Lark
Linkedin
MetaMask
Okta
QQ
Web3Onboard
WeChat
WeChat MiniProgram
WeCom Internal	Yes #2625
WeCom 3rd-party	Yes #2625
Weibo

Correct me if I was wrong.

[hsluoyz]

@leoncamel can you make PR?

[leoncamel]

@hsluoyz

OK. We will try to make PR for this. But, I think it involve big refactor on frontend & syncer interface and some core logic. And we are not sure if this PR will match casdoor's rodmap.

We will give try to make first PR to open discussion on this.

[hsluoyz]

@leoncamel I think this can be implemented by a new syncer. There's no need to build on top of the OAuth provider. They use different APIs and have nothing much shared in common.

[leoncamel]

@hsluoyz Yes.

But, I not sure how to share parameters between idP and its syncer. For the WeCom case, they may share ClientID and ClientSecret?

Any thoughts?

[hsluoyz]

@leoncamel no need to share. Just store it in syncer object for a second time