Fix spurious Products requirements.

Review Request #1662 — Created Jan. 25, 2015 and submitted — Latest diff uploaded

benjyw, ity, zundel

The trio of require, isrequired and get - the original members of
products - are tricky and they have invalid semantics in the
product-driven RoundEngine.

This change fixes things such that a `.get(<typename>)` does not have
the effect of causing a subsequent `.isrequired(<typename>)` check to be

Going forward, the idea of requiring a product for a subset of targets -
the role of the `.require` predicate today - will be subsumed by the
tuple-based engine.

src/python/pants/goal/ | 20 ++++++++----
tests/python/pants_test/BUILD | 1 +
tests/python/pants_test/goal/BUILD | 10 ++++++
tests/python/pants_test/goal/ | 0
tests/python/pants_test/goal/ | 89 ++++++++++++++++++++++++++++++++++++++++++++++++++
5 files changed, 113 insertions(+), 7 deletions(-)

I ran into this in the ProtobufGen imports handling in a pretty subtle
way when working on an engine change.

In (not so) short, ApacheThriftGen runs 1st, and in the post-processing
phase in the CodeGen superclass where synthetic targets are linked, a
call to products.get('python') ends up making 'python' products
required. This in turn influences the subsequent ProtobufGen (another
CodeGen sublclass) run, incorrectly telling it that 'python' protobuf
gen products are required.

CI went green here: