WIP: Fix data race (Repository.Units)

[typeless]

For #8205 (comment), #8205 (comment), #8205 (comment).

[lunny]

These races may be caused by permission's Units. I think a simple method is to change []*RepoUnit to []RepoUnit but not change more.

// Permission contains all the permissions related variables to a repository for a user
type Permission struct {
	AccessMode AccessMode
	Units      []*RepoUnit
	UnitsMode  map[UnitType]AccessMode
}

[typeless]

@lunny As I understand, the races are due to the concurrent access to the slice header (the ptr, len, and cap fields), besides the backing array. I am afraid that changing the type of slice element would not help. Maybe I am wrong, though.

It would be better if this can be solved by an architectural change that avoids sharing the data in any way. But I don't have a clear picture of how to do it.

[lunny]

Or we could copy the slices only but not change the slice element type. Permission's Unit is a reference of Repo.Units that has been changed by some other goroutines. I think that's the problem.

[typeless]

Another way is to fix the upper-level code by avoiding sharing the objects in the first place. One implementation I tried is to deep-copy the Issue objects before we forward them into different handlers. Unfortunately, the objects contain cycles, so I cannot use a library routine to accomplish that automatically.

I think there is a chance that we can pass the objects through the channels by value, not by pointers, to avoid sharing the memory.

[lunny]

Please resolve conflicts

[typeless]

@lunny I think this PR is not good. It touches too much code but does not address it fundamentally. We have to decide whether we want to make the model layer thread-safe (which is a big endeavor) or we take care of the concurrency problem at the upper layers (like passing the objects by values instead of pointers).