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.