Add new Queue Schedule methods

[fnetX]

Clear and concise description of the problem

On hosted instances like Codeberg, a single project with high demand can jam the queue easily. Since the hosting is shared, there is no incentive to optimize the pipelines, because if you put more work on the server, your total share from the server power will increase.

I think we need to allow different queue management options that allows for a fairer distribution in such environments, and brings incentives to optimize pipelines to save computing power, thus cost and environmental impact.

Suggested solution

I think we should add a queue option which limits parallel processing of jobs from the same origin, either repository or user/org.

Scenario outline

• UserA/repo1#1
• UserA/repo1#2
• UserA/repo1#3
• UserB/repo2#1 ← by default, this job has to wait, because the long runs all caused by UserA/repo1 jam the queue and might run in parallel or need to finish one after another first.

On a machine with two slots, instead of running UserA/repo#1+2 simultaneously, I recommend to run UserA/repo#1 and UserB/repo2#1 at the same time, and start UserA/repo#2 after #1 from the same user finishes.

Additionally, settings can be introduced to fine-tune this behaviour.

Alternative

A project might want to run pipelines on the main/dev branches with a higher priority than arbitrary pull requests. Pull requests marked as WIP are probably less important than ones that are waiting for immediate feedback.

Instead of using a "simple" method, a priority system could be established, and prio information could be provided via API (requires coordinated implementation). This is fairly more complex, but would be a flexible solution and ideally allow many imaginable use cases like serving paid customers in a company or security teams with higher priority in the CI system.

Additional context

No response

Validations

• Checked that the feature isn't part of the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]
• Read the Contributing Guidelines.
• Read the docs.
• Check that there isn't already an issue that request the same feature to avoid creating a duplicate.