[BEAM-9340] Populate requirements for Python DoFn properties.

[robertwb]

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Choose reviewer(s) and mention them in a comment (R: @username).
• Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue, if applicable. This will automatically link the pull request to the issue.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

Post-Commit Tests Status (on master branch)

Lang	SDK	Apex	Dataflow	Flink	Gearpump	Samza	Spark
Go		---	---		---	---
Java
Python		---			---	---
XLang	---	---	---		---	---	---

Pre-Commit Tests Status (on master branch)

---	Java	Python	Go	Website
Non-portable
Portable	---		---	---

See .test-infra/jenkins/README for trigger phrase, status and link of all Jenkins jobs.

[je-ik]

+1 Overall.
I have a minor concern, that I don't know how to solve exactly. As mentioned on ML, the set of requirements might not be static, but might depend on characteristics of input (e.g. if inputs are all bounded or not). Solution could be:
a) make the requirements a tuple (e.g. (bounded requirements, unbounded requirements), or
b) supply a logic that traverses the pipeline and creates requirements (that is, do not store requirements, but provide a logic) - I'm not sure how to implement this, or if it is even possible, or
c) ignore this nuance, because one can always declare the requirements as union of all cases, that would "only" make the pipeline fail although it could have run fine.

If we would be able (with reasonable certainty) to say that there will be no other conditions than if input is bounded or not, than I would tend to solution a). But I'm not sure about that. In the other case I would prefer solution c) (which is the current solution).

[robertwb]

Thanks for the quick review.

Responded about (a) on the list for more visibility. I think (c) is the way to go, runners can become more sophisticated about conditions in which they can satisfy requirements and SDKs can become more sophisticated about conditions in which they require them based on the pipeline context.

(BTW, I did think about (b) but wanted to try to keep the requirements as local as possible, and make it possible to declare requirements that are not explicit in the pipeline proto itself.)

[robertwb]

Rebased to deal with merge conflicts. Merging now.