Add a currency resolver API (with a CurrentCurrency object).

Can we revive this :-D

Pushed code from @zaporylie and added some basic test coverage for chain resolver and current currency

valic → changed the visibility of the branch 3039854-add-a-currency to hidden.

valic → changed the visibility of the branch 3039854 to hidden.

I'm generally not against the idea but it feels odd to me to define a new API Commerce itself isn't really leveraging? Reviewed the MR and left a few comments:

1. We define a new API, but besides defining a currency resolver, we aren't actually relying on the chain currency resolver? Maybe this is fine as this means no risk of introducing a performance regression I suppose.
2. I wonder if we should expand the Context object to be aware of the currency? Though it's always instantiated manually so perhaps not a good idea...
3. Perhaps we need a test price resolver that uses the new chain currency resolver as an example? Would have made sense to have it available from the Context I guess. At the same time... The order probably already has a currency when price resolvers are invoked for a given order item, so currency could be set using the order total currency code instead.
4. Perhaps we could extract the ServiceCollection from this MR: https://git.drupalcode.org/project/commerce/-/merge_requests/438/diffs#8... so we collect services the "new" way :).

Back to the last point, perhaps ServiceCollection should be renamed ServiceCollector and getCollection() to just getServices()? Or getCollectedServices()...

I decided to skip defining a service collector but instead went with the AutowireIterator attribute.

The ChainCurrencyResolverInterface could almost be skipped... We no longer need an addResolver() and we don't really need th getResolvers() method.

We could keep the interface to be able to distinguish between the chain currency resolver and resolvers themselves, but not 100% sure we need to expose the resolvers to the outside world... Kept it in case there is a usecase for accessing the resolvers? But we aren't even calling the getResolvers() method ourselves...

Also implemented return types and defined a service alias for autowiring.

1. Yes, it's not used anymore currently, so there is no changes in any of existing API-s.
2. Expanding context maybe have a sense, but it would introduce BC for that part. For majority of the shops probably which are single currency it does not benefit them, only multi currency which again is granulated how it's implemented

I am OK to RTBM this.

I did test with couple of my resolver, language, etc, it works great

Example of resolving per user language

@valic: Just wondering about keeping / reintroducing getResolvers() to expose the resolvers to the outside world.
If this is later needed, that means introducing a breaking change but at the same time, it may not be needed :p.

I don't see it as needed, from perspective of per example commerce_currency_resolver, I did now wrote three resolvers with different weights, so they can be used even simultaneously, etc: cookie resolver first, if there is no cookie, geo resolver goes next, etc..

Don't have need to interact with getResolvers()

I'm fine committing this as is, but giving @zaporylie an opportunity to review this since he worked on this (even though that was years ago).