[Fastlane.swift] take into account .fastlaneDefault case when retrieving OptionalConfigValue as a ruby argument

[rserentill]

Checklist

• I've run bundle exec rspec from the root directory to see all new and existing tests pass
• I've followed the fastlane code style and run bundle exec rubocop -a to ensure the code style is valid
• I've read the Contribution Guidelines
• I've updated the documentation if necessary.

Motivation and Context

When retrieving a OptionalConfigValue as a ruby argument, if the case is .fastlaneDefault (used for setting the values defined in configuration files such as Scanfile, MakeFile, Gymfile, Deliverfile, etc) the returned value is nil, instead of the default value.
Resolves #19196

Description

Added .fastlaneDefault case to return the appropriate value as a RubyCommand.Argument instead of nil.

Testing Steps

Tested the use case described in the open issue. Executed scan function in swift. It works on CI and it doesn't ask to select a scheme anymore when not in CI, it takes the correct value specified on the Scanfile.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[rserentill]

@googlebot I signed it!

[google-cla]

We found a Contributor License Agreement for you (the sender of this pull request), but were unable to find agreements for all the commit author(s) or Co-authors. If you authored these, maybe you used a different email address in the git commits than was used to sign the CLA (login here to double check)? If these were authored by someone else, then they will need to sign a CLA as well, and confirm that they're okay with these being contributed to Google.
In order to pass this check, please resolve this problem and then comment @googlebot I fixed it.. If the bot doesn't comment, it means it doesn't think anything has changed.

ℹ️ Googlers: Go here for more info.

[rserentill]

@googlebot I fixed it.

[joshdholtz]

This makes sense to me I think 😇 I'd like @minuscorp's 👀 on this before merging those since I'm not the expert on this part 😉

[minuscorp]

This will raise issues regarding conflicting options which was the main reason of separating this cases. For fixing this issue, I think the approach is how the values are picked from the Scanfile, to be set as .userDefined instead of .fastlaneDefault

[rserentill]

@minuscorp Thanks for your comments! you mean in the declaration of scan function to have scheme: OptionalConfigValue<String?> = .userDefined(scanfile.scheme) instead of scheme: OptionalConfigValue<String?> = .fastlaneDefault(scanfile.scheme)? what would be the point of having .fastlaneDefault case then?
Sorry if I'm missing something, I'm not very familiar with the actual purpose of OptionalConfigValue 😇

[minuscorp]

Usually .fastlaneDefault aims to cover arguments where there are values coming from fastlane itself instead of configuration files. We cannot detect if the Scanfile.scheme value has a default or a user defined one at runtime nor at compile time, so I assumed that the least harmful decision could be the current implementation, but not for the issue you have raised of course, so we should always send config files values, even if they are default ones.

[rserentill]

@minuscorp Ok, to make it clear, your suggestion is to use .userDefined in all the functions that use config file values in Fastlane.swift, instead of using .fastlaneDefault right?

[minuscorp]

Without being able to test it by myself right now, it seems to be a potential solution.