Improve slow user authorization if many orgs/repos

[MeurillonGuillaume]

This PR is a solution for #2502.

To resolve the issue a configuration option WOODPECKER_ASYNC_REPOSITORY_UPDATE has been added to allow administrators to decide how Woodpecker should deal with the repository update call that is part of the login flow. It can be either sync/async.
Sync is do-able for smaller organisations with few repositories, but larger organisations might opt for async to improve login speed at the cost of consistency. The repository list will be eventually consistent depending on the forge & store performance. The configuration flag was added to avoid altering default behavior for existing setups, unless changed by the administrator.

To improve UX for new users I made it mandatory for them to await the repository update, to avoid having new users log in to a blank homepage as this might be confusing. After this initial slow login they will also get async updates, and thus faster logins.

Closes #2502

[anbraten]

What do you think about letting the UI call the /refresh automatically. Basically:

1. click login
2. redirect to oauth with forge
3. redirect back to server (skip refresh, no need for a config option)
4. redirect back to the UI
5. the UI starts the refresh api call in the background
6. if done we update the internal repo store (this automatically reloads repo views etc)
7. and the UI redirects to the initially requested page

[MeurillonGuillaume]

Hi @anbraten

That is indeed an alternate approach to this issue, though I think it might get concerning at scale. Because

1. If everytime someone opens the /repos UI page triggers a full reload, that might end up triggering rate-limits on the forge, given enough users, organisations and/or repositories
2. I don't think repository access will in many cases change often enough to need to be reloaded (automatically) so often. In case there are actual changes that are not yet picked up, one can refresh manually with the UI change.

It could perhaps be an automated action in the login flow, which it is already with this change. Having it configurable is maybe unnecessary, but I didn't want to alter the behavior for organisations that have no problems currently.

[woodpecker-bot]

Surge PR preview deployment succeeded. View it at https://woodpecker-ci-woodpecker-pr-5665.surge.sh

[lafriks]

What do you think about letting the UI call the /refresh automatically

Isn't login sync used also for repo/org rights checks?