Add argument --ignore-available-on to ignore availibility of specific packages

[WardBrian]

This is a proposed new argument to resolve the feature request in #5283.

I've decided to make it a separate argument from the --ignore-constraints-on argument mentioned there, but it's an easy modification if we'd prefer that argument to do double duty.

As a minimum demonstration, here is me trying to install the osx-plutil opam package, which is marked as only available on macos, on my ubuntu machine:

$ ./opam install osx-plutil 
[ERROR] osx-plutil: unmet availability conditions: 'os = "macos"'
$ ./opam install --force-available osx-plutil osx-plutil 
The following actions will be performed:
=== install 3 packages
  ∗ osx-plutil 0.5.0
  ∗ process    0.2.1 [required by osx-plutil]
  ∗ result     1.5   [required by osx-plutil]

Proceed with ∗ 3 installations? [Y/n] n

I have thus far made exactly the set of modifications that seemed necessary to get this working and no more.
I suspect that there is at least a couple more places this information would need to be propagated to be 'feature complete', but I decided to pause here to kindly ask for feedback on the general approach before continuing.

Fixes #5283

[kit-ty-kate]

This looks globally really good, thanks a lot. Modulo this single command i don't see anything wrong on first glance.

Do you have extra time to add some tests for this feature? If not we'll do it whenever we get around to properly review this.

If you do, the documentation can be found here: https://github.com/ocaml/opam/tree/master/tests/reftests#readme and all the commands that use build_options should probably be tested for completeness (e.g. install, reinstall, remove, upgrade)

[WardBrian]

@kit-ty-kate tests added! This also forced me to flesh out the other places that it is needed, and move the logic into a single val force_available: 'a switch_state -> OpamPackage.Name.Set.t -> 'a switch_state function, which means that I no longer needed to add ?force_available arguments to all the functions, I just give them a switch state with the already-good-to-go availabilities.

I think this is better, and it might even make sense to roll into the OpamSwitchState.with_ function, but I didn't want to go touching too many existing systems.

Edit: I moved the logic into OpamSwitchState.load, as this seems like a central place that already reads from OpamStateConfig

[kit-ty-kate]

a couple of minor comments to remove now unused additions

[kit-ty-kate]

Thinking a little bit more, i think the option might be better named --ignore-available-on to make it more clear that the option is expecting an argument, to make it easier to search for people coming from --ignore-constraints-on and to avoid clashes with a potential future --force option.

@rjbou what do you think?

[WardBrian]

I do not believe that the code you've flagged above is unused -- deleting it and chasing down the subsequent compiler errors ends up essentially reverting the PR.

i think the option might be better named --ignore-available-on

Happy to go with whatever name is preferred

[kit-ty-kate]

I do not believe that the code you've flagged above is unused -- deleting it and chasing down the subsequent compiler errors ends up essentially reverting the PR.

mmh, that doesn't sound right. These 4 lines are all related to the parsing of the OPAMFORCEAVAILABLE environment variable that was removed. My only mistake was to suggest the removal of ?force_available:(...) instead of ?force_available:None. With this it compiles and works just fine.

[WardBrian]

?force_available:(...) instead of ?force_available:None. With this it compiles and works just fine.

Indeed, that was the piece that was breaking everything if I let the compiler guide me (The ml/mli disagreement errors you get when dealing with both continuations-style functions and module includes are not something with which I am all that fluent).

[kit-ty-kate]

lgtm modulo some really minor stylistic choice (we generally have a 80 columns rule for new lines of code) and commit reorganization, that we can do ourselves just before merging by force-pushing.

I'll let @rjbou do a second review, but overall i believe this should be good to go in 2.6 whose first alpha is planned around February

[WardBrian]

Thanks for the pointers!