Allow offer rescoring

[johny-b]

1. Currently we score offer only once and later use this score forever, with the only exception being rare calls to AgreementsPool.offer_recycler.
2. There are lot of reasonable market-strategy-logic-things that are impossible to implement with this restriction (like, a simple "I tried this provider and I'm not happy with their performance, so I want to score their offer lower").
3. Changing this should be quite easy, as we already have engine.recycle_offer exactly for this purpose.

The only problem is to decide the interface, few ad-hoc ideas:

• no interface, just rescore every offer on a given moments, e.g.:
  • when we consider sending an agreement proposal
  • when we end an agreement with the provider
• Golem.rescore_offer(offer: OfferProposal) <- that's probably not very good, since currently there's no direct access to the past proposals
• Golem.rescore_offers(provider_id: str) <- probably a pretty good one

ALSO:

• find references to this issue in yapapi
• fix appropriate places (e.g. yapapi.contrib.strategy.ProviderFilter)

[shadeofblue]

market ...

plus, I guess the rescoring should be somehow bound to the job - since we might be scoring offers differently depending on the demand ...

so, it seems to me that the interface should be Golem.rescore_offers(provider_id, job_id) ... but also -> what happens them? are those offers just again sent to the strategy's score_offer?

anyway, I just sent you @johny-b my thoughts on strategy in Golem on priv... I think we should make the strategy more explicitly bound to the task at hand rather than allowing it to be changed randomly...

[johny-b]

<3 market <3

@shadeofblue Yes, I think offers should be just resent to score_offer

About the rest - hmm, I'm not sure, but the current implementation is a little confusing for me:

1. We have a single golem.strategy
2. We don't know the job we're scoring offer for (job_id is not available in score_offer)
3. Yet we have different sets of offer-scores for all jobs.

I understand that the sets are different, because with different payloads we have different offers (and we might e.g. want to negotiate in a different way). But still, I don't see a reason why a raw offer on the market has two scores for two different jobs, when there is no logic that would let us score them differently.

[johny-b]

As discussed today with @stranger80 and @shadeofblue:

1. This sounds like a useful feature and currently there's no clean solution.
2. There are at least two avenues: A) AgreementPool will listen on some events emitted directly from the MarketStrategy (this might have nothing to do with the current yapapi events). B) Extended MarketStrategy interface: MarketStrategy would have a queue/generator/whatever that always returns the current best offer. Our current take is that B seems better, mostly because it is much more flexible (i.e. this interface will let us implement much more complex strategies in the future).
3. B seems to be not-very-hard to implement without any backward incompatible changes (MarketStrategy would internally consume raw offers, call self.score_offer, keep stored offers and return those that have highest scores).
4. B is quite similar to the offer_generator concept from the "mid-level API concept" (aka "yapapi dream interface"), so maybe they should be somehow considered together.