feat: Validation for conditionally required/forbidden fare_rules.txt file.

[bdferris-v2]

Summary:

Per updates introduced in the Fares v2 spec addition, we now check for the conditionally required/forbidden fare_rules.txt file.

Please make sure these boxes are checked before submitting your pull request - thanks!

• Run the unit tests with gradle test to make sure you didn't break anything
• Format the title like "feat: [new feature short description]". Title must follow the Conventional Commit Specification(https://www.conventionalcommits.org/en/v1.0.0/).
• Linked all relevant issues

[bdferris-v2]

@isabelle-dr per discussion, here is a separate PR for the Fares v1 file checks.

[KClough]

LGTM

[isabelle-dr]

2 minor changes in line.
Can you resolve the merge conflicts?
Then, I'll merge this PR!

[bdferris-v2]

@merge conflicts have been resolved

[bdferris-v2]

Pasting this in manually:

❌ Invalid acceptance test.
New Errors: 62 out of 1363 datasets (~5%) are invalid due to code change, which is above the provided threshold of 1%.
Dropped Errors: 0 out of 1363 datasets (~0%) are invalid due to code change, which is less than the provided threshold of 1%.
1 out of 1364 sources (~0 %) are corrupted.
Corrupted sources:
de-unknown-ulmer-eisenbahnfreunde-gtfs-1081
Commit: e0746f5
Download the full acceptance test report here (report will disappear after 90 days).
❌ Invalid acceptance test.

I was curious what this was going to trigger. Taking a closer look.

[isabelle-dr]

Isn't having fare_rules.txt going from Optional to "Required if fare_attributes.txt is defined" (which was a pre-existing Optional file), a breaking change?
I'm not surprised that we have some existing datasets becoming invalid.

[bdferris-v2]

I'm a little confused by the change to the spec as well.

Looking back at the original Fares V1 example documentation (not really hosted anywhere anymore, but available at https://web.archive.org/web/20111207224351/https://code.google.com/p/googletransitdatafeed/wiki/FareExamples), having a fare_attributes.txt file with a single entry and no fare_rules.txt file was a supported use-case for systems that have a single base fare. This was actually brought up in a comment by @flocsy but I think his feedback was ignored?

And indeed, when I look through the acceptance report for this change, there are 62 feeds in the MobilityDatabase that have a fare_attributes.txt file but no fare_rules.txt file. Of those, 39 have a single entry in fare_attributes.txt, indicating a default fare.

That said, there are also 11 feeds where fare_attributes.txt has no entires (but still has a CSV row header). I'm not sure how that should be interpreted? A free fare? There are additionally 10 feeds that specify multiple fare_attributes.txt entries where fare_rules.txt looks like should legitimately be specified.

I'm tempted to say "pause" on this PR and get some feedback from the #gtfs-fares group before proceeding.

[isabelle-dr]

@bdferris-v2 I am closing this since we decided to modify the spec and not the validator for this one.
We can eventually keep the addition of forbidden_file to use in other cases. I'll let you decide if you'd like to open another PR for it :)