@wxiaoguang Please take a look at this approach

The last ask: are we ready and do we have enough courage to break many existing users' upgrade operation and force them to manually edit their config file? If yes, mark this PR as breaking and add a "breaking" section to tell users what would happen and what they should do.

also cc @go-gitea/maintainers

The last ask: are we ready and do we have enough courage to break many existing users' upgrade operation and force them to manually edit their config file?

I'd say yes. All those options where deprecated 3 or more releases ago and therefore could technically been removed anytime and unfortunately there's no premade solution for managing settings at this level.
This is better than endlessly supporting the legacy syntax and forces users to do a config cleanup.
Alternatively gitea could rewrite those options but frankly I'm not a fan of an app writing to it's configuration file - plus in k8s/ansible installs where the config is updated by user it would cause more confusion.

The last ask: are we ready and do we have enough courage to break many existing users' upgrade operation and force them to manually edit their config file?

I'll stay neutral on this topic as I can see both advantages and disadvantages to this idea.
As stated previously, these config options have been deprecated for quite a long time (Gitea 1.19 was released on March 20, 2023, so two years ago).
At some point, we will have to remove the fallbacks.
The only question is: when do we remove them?
Now? In a year? In two years?
When will enough users have migrated to the new version that this operation will be fairly safe?
So far, I explicitly refrained from commenting on this PR as I expected you to ask exactly this question.

@wxiaoguang, how long would you keep them?
I do understand that 2 years is still comparably short, so I'm also fine with waiting another year or two with removing them.
But if someone doesn't keep their Gitea up to date in four years, they never will unless forced to.

These deprecations have been shown on the admin page for a long time, I'm fine with removing and calling out the alternatives in the release notes.

@wxiaoguang, how long would you keep them? I do understand that 2 years is still comparably short, so I'm also fine with waiting another year or two with removing them.

Hmm yes, we had never introduced so many breaking changes in one release, TBH I don't know how end users would react to this. If they would feel frustrated for making so many changes in one release upgrade, they would give up and stay with the versions which have security vulnerabilities ......

So taking some progressive actions and waiting for more time seem reasonable.

From my own pov - I did look through release notes (mainly for new features) and I haven't been maintaining app.ini on regular basis which after 2/3 releases was not a fun time (though it's because I did it "wrong" since I wanted to sync it with package manager example which was a terrible idea). So I'd argue that without a clear fault signal to the administrator no amount of warning will get everyone to migrate the configuration.

I'm fine with waiting for longer or for better ideas but this is a bridge that will need to be crossed eventually with a good future proof plan. Keeping deprecated config values forever is not feasible or a good idea in general.
We can postpone this for a rewrite of settings module.

I feel like 3 releases back is generally "good enough" - especially since it's technically major version change every time and there are cases where a flag/config is deprecated from 1.x -> 1.y and then removed in 2.0.0.

More related to the settings issue in general than PR:

I've also looked at existing systems (viper, koanf) but they won't provide what we need here (deprecation warnings and removal) so a custom solution would be required anyway.
Having a migration layer (similar to DB) - while it's a nice idea it cannot be applied on the config file directly, so it would require a cli endpoint to handle it (which is generally a good idea in the first place so solutions like ansible can use it to validate the configuration early).
I don't think a system where an old config (say 1.20 one) can be used for a newer version (1.24) and it automigrates itself in the background without user updating their configuration.

I'd like to help rewrite/refactor the settings system but for that we'd need to gather requirements - my own being TOML support and json schema for settings.