Move code to "macros" and "session" features

[pgherveou]

Moved bundle and mocking under session.
Alternatively we could keep it where it is but put this code behind other feature flags

This change is needed, cause the current setup introduce dependency cycle with ink!.
ink! should import drink! without the session feature to avoid creating a dependency cycle

[pmikolajczyk41]

what exactly is the dependency cycle? drink doesn't depend on ink!, does it?

[pgherveou]

what exactly is the dependency cycle? drink doesn't depend on ink!, does it?

it does through contract-transcode (that is only required by feature session after this PR), we don't need all the session stuff in ink! as well

[ascjones]

what exactly is the dependency cycle? drink doesn't depend on ink!, does it?

it does through contract-transcode (that is only required by feature session after this PR), we don't need all the session stuff in ink! as well

Exactly.

drink -> contract-transcode -> ink_metadata + ink_env
^                                               ^
|                                               |
ink_e2e ----------------------------------------

[pmikolajczyk41]

am I correct, that it is necessary to put only contract_bundle_provider behind feature gate? test should be fine

[ascjones]

Just looked and the drink_test_macro crate also brings in contract-build and contract-metadata crates which would also cause a circular dependency, so maybe we should make drink_test_macroa dependency feature of drink?

[pmikolajczyk41]

hmm, yeah, that sounds more reasonable... especially that I don't like hiding macros behind session feature

so I suggest introducing second default feature macros and feature-gate reexport here (and the dependency as well)

[pgherveou]

Done. I am testing this with ink! fyi, to make sure we don't forget stuff.
Quick question we should also build with just the std feature (the one we will use in ink!)
What's the best way to check that the code does not generate warning

just a new step in the rust-checks.yml?

[pmikolajczyk41]

what warning do you have in mind? and yes, I guess adding some check to CI is the best idea