Remove unused flags / options

[anbraten]

some flags where unused and / or unnecessary as they are covered by alternatives implemented in PRs of milestone 0.15.0 and just complicated the setup.

closes #681

[6543]

I still think we should not drop feature to set custom status context

-> #674

[6543]

normally we dont want the git clone step only to authentificate if needed (repo != public)

but if you set REQUIRE_SIGNIN_VIEW at [service] in gitea (for example - gitlab can be configure similar) you need th auth on "public" repos too (forge api tell us it is public but it is not ...)

I propose: a global bool flag (config) for all forges (similar to context-prefix) to enforce netrc generation

[6543]

so it's not handled for each remote provider but as a global option for woodpecker itself

[anbraten]

Why shouldn't we always use NETRC credentials to clone repos? We have that data.

[6543]

because it's sensitive data aka. an secret and if it's not within public repos it has no chance to get leaked at all

[anbraten]

I disagree on that. If passing the secrets is such a high security risk we have that problem for private and public repos and need to think about an alternative for both. As we only pass it to our "verified" clone image at the moment I don't see that it is a security issue.

One thing I want to make clear is the current implementation of PRIVATE_MODE. It is currently not used to decide if we pass NETRC data or not. From how I read the code the only thing it does is setting the woodpecker projects visibility docs. In the case a project is public in the SCM the private mode currently ignores the SCM visibility and sets the woodpecker project visibility to private as well. IMO this isn't really needed. We can simply set the woodpecker projects visibility to the same as the repos visibility of the remote SCM. If a user prefers to change it he is welcome to do so in the UI settings of his wp project.

If we later want to allow the system admin to disallow public access completly, because he only want to allow access to employees for example, we can simply readd a global option, which would change the whole UI & api to always require auth, but that would be a new feature IMO.

[6543]

hmm well I think the edgecase I mention is also broken in current state - so lets remove things and if it's needed add a new flag for this specific case ...