Avatars and Repo avatars support storing in minio

[lunny]

As a next step of #11387

[codecov-commenter]

Codecov Report

Merging #12516 into master will decrease coverage by 0.03%.
The diff coverage is 33.79%.

@@            Coverage Diff             @@
##           master   #12516      +/-   ##
==========================================
- Coverage   42.59%   42.56%   -0.04%     
==========================================
  Files         671      674       +3     
  Lines       73625    73724      +99     
==========================================
+ Hits        31363    31380      +17     
- Misses      37183    37253      +70     
- Partials     5079     5091      +12     

Impacted Files	Coverage Δ
cmd/migrate_storage.go	0.00% <0.00%> (ø)
models/migrations/v115.go	0.00% <0.00%> (ø)
models/repo.go	56.83% <0.00%> (+1.67%)	⬆️
models/repo_generate.go	12.50% <0.00%> (ø)
routers/repo/setting.go	14.69% <0.00%> (ø)
routers/user/setting/profile.go	40.93% <0.00%> (ø)
routers/routes/routes.go	85.86% <23.68%> (-3.14%)	⬇️
models/user_avatar.go	27.47% <27.47%> (ø)
models/repo_avatar.go	31.81% <31.81%> (ø)
models/org.go	73.75% <33.33%> (+0.14%)	⬆️
... and 20 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c6da033...b419c9f. Read the comment docs.

[lunny]

It's ready to review.

[lafriks]

Imho there should be single avatar storage for both user and repo avatars

[zeripath]

I still think a common [storage] ini section would have been cleaner than spaffing MINIO configuration options in to the configuration for everything you're adding storage to.

[lunny]

Imho there should be single avatar storage for both user and repo avatars

I think we can do that via setting the same configuration for user avatars and repository avatars.

[zeripath]

We now have to describe both minio and local storage settings in cheat sheet and app.example.ini:

• [attachment]
• [lfs]
• [avatar] (twice)

With exactly the same text and meaning for slightly different keys.

If we add a new storage option the code situation is even worse: as every time we add a new storage option we need to change:

• modules/setting/lfs.go
• modules/setting/attachment.go
• modules/setting/picture.go (twice)
• cmd/migrate_storage.go
• modules/storage/storage.go
• routers/routes/routes.go (twice)
• Then add descriptions to config cheat sheet and app.example.ini in all of the above places and anywhere else we add storage options to.

Compare with adding a new queue option:

• add a file in modules/queue
• add a const type:

// ImmediateType is the type to execute the function when push
const ImmediateType Type = "immediate"

• add a Queue type:

// Immediate represents an direct execution queue
type Immediate struct {
	handler HandlerFunc
}

...

• add a creation function:

// NewImmediate creates a new false queue to execute the function when push
func NewImmediate(handler HandlerFunc, opts, exemplar interface{}) (Queue, error) {
	return &Immediate{
		handler: handler,
	}, nil
}

• add an init function:

func init() {
	queuesMap[ImmediateQueueType] = NewImmediateQueue
}

• Describe it once in config-cheat-sheet.md and in app.example.ini <- this is missing for the immediate queue type it appears.

Every place that uses queues can now use the immediate queue without having to think about it further.

[lunny]

see #12813

[lafriks]

@lunny please resolve conflicts

[lunny]

@lafriks done.

[zeripath]

I really think we should get #12978 in as it would show a way to simplify the settings somewhat.

[lunny]

@zeripath done.

[6543]

🚀