feat!: improve gherkin files

[aepfli]

I looked at our Gherkin files, and I feel we can optimize them slightly. They're sometimes hard to use.

• Transferred a lot of When into Given
• split flag actions into smaller chunks (one for reason, one for value, one for variant) instead of merging them into one
• added tags throughout the test suite to easier enable disable features (not by loading files, but by defining tags)

⚠️ Breaking Change

• changed how flags etc, are evaluated; current test suites won't work anymore
• Flag evaluation now differs from the spec gherkin file. We could also adapt the spec gherkin file or create one here; I am open to both solutions.

[aepfli]

relates to #166

[aepfli]

open-feature/java-sdk-contrib#1115 and open-feature/python-sdk-contrib#121 and open-feature/js-sdk-contrib#1129

Those need to have a little bit more work still, as they're not 100% feature complete, but show the process in general

[aepfli]

@toddbaert @beeme1mr I would love to move forward with this. I have implemented reference implementations within Java and Python (also using tags to exclude features), which work great (except for Python 3.8, which is a little sad, but I can't fix the tooling).

(teaser: I also have a socket path implementation for Python with this test suite ready)

Let me know what you think :)

[toddbaert]

This is a bit of a nit, but if I understand correctly, we can use Scenarios here instead of Examples which I think is just clearer (using SSL or a target URI seems more like a specific "scenario" to me than an "example". Example just sounds like example data, but this is a different mode of operation, not just different sample data.

If this is a difficulty, I'm fine with Examples, but my understanding is they are synonymous in cucumber.

[toddbaert]

I think we should update this name to match the file name better, or vice-versa... maybe "flag custom targeting features"

[toddbaert]

Same here, can we make the filename and Feature a bit more similar?

[toddbaert]

I looked at the draft implementations and they look good, so I don't have any major compatibility concerns. I left some notes about minor discrepancies I found between some content and file names, and also suggest some alternate keywords for clarity.

Flag evaluation now differs from the spec gherkin file. We could also adapt the spec gherkin file or create one here; I am open to both solutions.

I think we should update the spec gherkin, this format looks better.

Breaking Change

I think another thing we should do is make this a 1.0 release... mostly because we mostly (only?) use this internally and then we could more easily express breaking changes going forward. You can do this by adding "release-as": "1.0.0" in the release please config here:

flagd-testbed/release-please-config.json

Line 5 in 8931c86

"release-type": "simple",

(and then we remove it after the release). I think it's fine to do that in this PR. If we make more breaking changes that's fine, we can be on v15 of this next month IMO and it won't hurt.