refactor: decouple context from migration structs

[TheFox0x7]

---

I've started working on pulling out contexts from structs per golang conventions and I took migrations on first.
It should be fine apart from gogs which I have no idea how to decouple - safe for updating/forking gogs client.

Ideas and initial feedback are very much welcome.

[wxiaoguang]

I've started working on pulling out contexts from structs per golang conventions

I think it depends on whether it really brings enough benefits. Golang itself (official packages, for example: http) also store the ctx into struct field in many cases .........

[TheFox0x7]

According to the go's blog post the only reason why net/http has context in its struct is backwards compatibility:
https://go.dev/blog/context-and-structs
And it's not recommended to store it there.

[wxiaoguang]

According to the go's blog post the only reason why net/http has context in its struct is backwards compatibility: https://go.dev/blog/context-and-structs And it's not recommended to store it there.

Yup, that's same to Gitea's code base. New code seldom stores context into a struct.

Some old code already stores the context into the struct, which is not good, while not too bad if it hasn't caused any problem (for example: markup render also does so). That's what I meant "I think it depends on whether the refactoring really brings enough benefits."

---

For "gogs downloader", the NewClient is quite lightweight, if you'd like to make the downloader support context, maybe it could re-create the client in every function.

[wxiaoguang]

As a refactoring PR, I think we'd better to make it move on fast (to avoid unnecessary conflicts)

If "gogs client ctx" is the last blocker, maybe I could help to try to figure out how to make it work (edit this PR) if you don't mind .......

[TheFox0x7]

Sorry for the delay, I started jumping between various topics semi-related (like what kind of magic makes gitea's context for request handlers) and unrelated (checking if migrating swagger to oapi-codegen is doable) to this.

I figured that probably the best solution is to make the gogs library have context support so I went ahead and added it in my fork.

[wxiaoguang]

I figured that probably the best solution is to make the gogs library have context support so I went ahead and added it in my fork.

Hmm, I prefer to keep using the official one (although it isn't active), in case the official one gets updated we might miss it.

The forked dependencies are difficult to maintain TBH. I think the gogs client ctx could be fixed by #33399 (comment)

[TheFox0x7]

The change isn't that big that a rebase once a while can't deal with. Though I see your point.
Can you share a snippet of code with your idea for a fix then? I figured you meant just creating new client per function but I don't see how context comes into play there...

[wxiaoguang]

-> Make gogs client work with context TheFox0x7#1

---

The reason why I don't want to introduce more forked packages:

• It takes extra work to maintain.
• It's difficult to follow upstream changes.
• If there is a dependency security vulnerability detected (by some bots/tools), our fork will miss it.

ps: see the comment for another fork (just below): // TODO: the only difference is in `PutObject`: the fork doesn't use `NewVerifyingReader(r, sha256.New(), oid, expectedSize)`, need to figure out why .........