vendor/open-simulation-interface: Add full_package_mode

[fgguidi]

Set full_package_mode for Protobuf to consider the case that a consumer recipe might set Protobuf as a shared or static library.

How to reproduce issue:

• Set the following options in your consumer: 'self.options['open-simulation-interface'].shared = True' and
  'self.options['protobuf'].shared = True'
• Then upload the packages to artifactory.
• Now change self.options['protobuf'].shared = False in your consumer package.
• Try to compile again. Assuming that your Conan configuration has as default `default_package_id_mode = semver_direct_mode' then the first version of OSI produced which links to a Protobuf as shared library is installed in your Conan cache.

[cassava]

Part of the goal of these vendor(ed) packages is to be as close as possible to the recipes that are used on Conan Center. This allows us to use the CCI versions as soon as they are sufficient. For a while, we had this for all vendored packages.

Adding this full_package_mode in the package_id method here is nice, but it is a deviation from the way that packages are written in the CCI:

https://github.com/conan-io/conan-center-index/blob/master/recipes/open-simulation-interface/all/conanfile.py

If you rely on it, things will break again if we want to revert to the CCI version again. It seems Conan expects you to define something rational in the conan.conf, (which can be part of the configuration you are expected to be installing when deploying Conan in an organization):

https://docs.conan.io/1/creating_packages/define_abi_compatibility.html#changing-the-default-package-id-mode

Also note the comment on Conan v2:

https://docs.conan.io/1/creating_packages/define_abi_compatibility.html#enabling-full-transitivity-in-package-id-modes

So it seems to me that the better course of action would be to ensure that conan.conf is set correctly for all consumers. The defaults for Conan v1 are anyway not recommended to be used for a while, meaning the effort needs to be done one way or another.

Do you agree with the logic?

[cassava]

That all said: Merging this PR isn't going to break anything so I'm not against it. You have to address the underlying issue too otherwise something will break again in the future.

[fgguidi]

That all said: Merging this PR isn't going to break anything so I'm not against it. You have to address the underlying issue too otherwise something will break again in the future.

I understand your point and I agree that changing this recipe is then not the permanent solution for our issue. I will proceed to merge this PR just to signal this issue for the future and that we eventually have something in the history that can help if it happens again but we will not depend on this solution.
I have temporarily fixed the issue without having to depend on the fixed recipe.