Apply soft restrictions to fork visibility
Description
The visibility of a fork cannot be more permissive than the source project. This makes sense. But it becomes messy when the source project changes its visibility, temporarily or permanently. Couple cases:
- Internal or private source project.
- User forks the project, would like it to be public, but it's currently not allowed.
- Source project changes to public.
- It would be nice if the fork changed to public too (if that's what the user wanted).
After #33358 (closed), whenever a project reduces its visibility, all fork relations are removed. I find this quite annoying and disruptive. The decision to break the fork relationship should be on the fork owner, not the source project. See #36238 too.
Proposal
Allow the forks to set any desired visibility level, even higher than the source project, but in practice apply only the lower of the two. This would be similar to other settings, like runner timeout, which can have different values (in the project or the runner) and the lower one takes priority.
This would allow users to create forks with their desired visibility, and it would be effective whenever it is allowed by the source project. It would also make forks mostly immune to accidental or temporary changes in the source project, provided the fork relationship is not automatically broken when the source project's visibility is reduced.
Similar soft restrictions should be applied to repository visibility, which would solve #36662 (closed).
There should be a clear UI indication that the chosen visibility option is overridden by the source project, when that is the case.