Add functionality to get active rules for a branch

[ihrigb]

Description

Add methods to get all active rules for a branch.

Before submitting a PR:

• Changes must not break binary backwards compatibility. If you are unclear on how to make the change you think is needed while maintaining backward compatibility, CONTRIBUTING.md for details.
• Add JavaDocs and other comments explaining the behavior.
• When adding or updating methods that fetch entities, add @link JavaDoc entries to the relevant documentation on https://docs.github.com/en/rest .
• Add tests that cover any added or changed code. This generally requires capturing snapshot test data. See CONTRIBUTING.md for details.
• Run mvn -D enable-ci clean install site locally. If this command doesn't succeed, your change will not pass CI.
• Push your changes to a branch other than main. You will create your PR from that branch.

When creating a PR:

• Fill in the "Description" above with clear summary of the changes. This includes:
  • If this PR fixes one or more issues, include "Fixes #" lines for each issue.
  • Provide links to relevant documentation on https://docs.github.com/en/rest where possible. If not including links, explain why not.
• All lines of new code should be covered by tests as reported by code coverage. Any lines that are not covered must have PR comments explaining why they cannot be covered. For example, "Reaching this particular exception is hard and is not a particular common scenario."
• Enable "Allow edits from maintainers".

[codecov]

Codecov Report

Attention: Patch coverage is 98.13084% with 2 lines in your changes missing coverage. Please review.

Project coverage is 81.29%. Comparing base (cab9bbb) to head (f3e03d3).

Files	Patch %	Lines
...main/java/org/kohsuke/github/GHRepositoryRule.java	98.05%	1 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##               main    #1897      +/-   ##
============================================
+ Coverage     81.05%   81.29%   +0.24%     
- Complexity     2442     2450       +8     
============================================
  Files           237      238       +1     
  Lines          7342     7449     +107     
  Branches        398      400       +2     
============================================
+ Hits           5951     6056     +105     
- Misses         1145     1146       +1     
- Partials        246      247       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[bitwiseman]

I like the idea you have going with Parameter<T> and the instances defined in the Parameters interface, but I'm not sure it's the right way to go.

I noted a bunch of style and detail changes. You can choose to do them or hold off until I wrap my head around the Parameter design and figure out how I feel about it.

[ihrigb]

@bitwiseman I will take care of your suggestions.

As of the Parameter vs. Polymorphism topic I had to thoughts about it as well. The parameter way turned out to be more flexible, if GitHub does any change to the API (not sure, if that would happen with the current version being almost two years old). Using polymorphism would result in weird Java code with instanceof stuff and casting types. Happy to discuss this either way.

[bitwiseman]

Which value of the GHRepositoryRule.Type enum applies here? Is it suppose to be REQUIRED_LINEAR_HISTORY?

I'm fine with Parameter<T> taking string in the constructor, but in Parameters I want those strings to be generated from GHRepositoryRule.Type to reduce the likelihood of the strings here getting out of sync with the enum values.

[ihrigb]

I am not sure, what to do... Enum values cannot have static fields if you think about sth like Type.REQUIRED_LINEAR_HISTORY.UPDATE_ALLOWS_FETCH_AND_MERGE.

[ihrigb]

@bitwiseman what should I do here?

[bitwiseman]

Thanks for sticking with this through multiple rounds of feedback. This is looking great, I think this is the last cycle and then we'll be able to merge.