Revisit pattern for defining if contractimpl is exported

[leighmcculloch]

Today we specify if a contractimpl is exported with the export_if attribute which accepts a feature. This requires the contract developer to proactively add a feature to their crate that is used to gate whether the contract impl is exported. If the attribute isn't provided it is assumed to always be exported.

I think we need to revisit this pattern. The pattern is simple to implement for us, and flexible for contract developers, but it has one undesirable quality for contract developers:

It is opt-in. Developers who don't set an export_if always export, which means that their crate is likely never importable by other contracts. Anyone importing their crate will possibly unknowingly re-export their exports, and there is little that the importer can do about it.

Ideally the solution we use for controlling whether the functions are exported is not opt-in, and by default the contractimpl macro sets a contract such that it is importable safely, but when built for itself is always exported.

Ideally the solution would involve automatically detecting if a crate is being built as a dependency or as the primary package.

It's unclear if there is a better solution than what we have now given constraints of rust/cargo, but I think it's worth us having a look to see.

[leighmcculloch]

An attempt to use CARGO_PRIMARY_PACKAGE instead of a feature as a way to identify if a crate is being built for itself or as a dependency is here: #407. It is not viable given the reasons on the PR.

[leighmcculloch]

I thought maybe we could use a cfg on crate_type as a way to conditionally compile in the exports so they are only exported for cdylib and not rlib, but that is currently not possible with cargo:

• Add cfg for crate_type? rust-lang/rust#45182
• Conditional compilation based on crate_type rust-lang/rust#20267.

[leighmcculloch]

Going to close this in favor of #409.