Move notification package to services

[KN4CK3R]

The notification package relies heavily on different models which is disallowed by our definition of modules. This helps to prevent possible import cycles.

Does this replace #22256? @delvh Does this fix the same import cycle problem you encountered? This PR was an easy change because only the imports need to be changed.

[delvh]

Well… The problem I have with that:
If we do it like that, we won't have much left in modules at all.
That means that we have to watch more closely how each subpackage interacts with each other to avoid an import cycle.
And that just shifts the problem down again, and makes an easily identifiable problem much more complicated to identify (It's easier to see a cycle across different top-level packages than it is across sub-packages with the same top-level package).

---

As I mentioned in #22256 (comment), the reason, I implemented the PR as it is, is that #21937 again tries to access the constants I extracted from models inside modules.
So, should we decide to merge this PR, everything I moved from models/webhooks into modules/webhooks will still need to be moved at some point. (perhaps except for the errors, as there is currently a discussion if they should stay where the corresponding type is declared, or in modules)

[KN4CK3R]

Could you point me to the place in the actions PR with the problem you try to solve?

[delvh]

modules/actions/workflows.go: https://github.com/go-gitea/gitea/pull/21937/files#diff-036ba47e66a4d37724ab4b27cbf7d25ae108771f152ea5176372d31cc9239e01R47

[KN4CK3R]

It's simply wrong to add DetectWorkflows under modules?

[delvh]

Not if the constant is not inside models, but inside modules.

[KN4CK3R]

Yes, I agree that moving the HookEventType may be a good idea then. I have these constants in the package registries under modules too. So this PR does not replace #22256 and both PRs are not mutually exclusive.

[lunny]

Since we can move all notification implementation out of modules, I think we can leave notification interfaces and related functions in modules. @delvh 's PR for webhook is a good direction. We can do like that for mail, actions and etc. step by step. But I don't think move all notification packages to services is a good idea, otherwise we will encouter the situation that many services packages depend on other service packages which could be avoid.

[KN4CK3R]

I think we can leave notification interfaces and related functions in modules.

The interfaces depend on models and therefore can't reside in modules.