Change cherry-pick bot behavior when a parent is not yet picked

When a relation chain of changes are submitted together, there are factors like internal gerrit queues and network latency that cause the real availability of cherry-pick ancestry to be unpredictable. The current behavior deals with this by testing for the expected parent's existence twice before falling back to walking the relation chain to find the first parent in the ancestry which exists on the target branch. This is often okay, as any picked changes which cause a merge conflict then wait for the expected parent to be created, then being rebased, resolving the conflicts. But in some cases, an important change from a relation chain may apply cleanly to an earlier ancestor or even HEAD, but is still a required change for further child changes.

When a relation chain is broken like this, phantom merge conflicts can appear. Thus, a change in strategy is needed. The bot should always try to wait for the expected changes first, provided that the expected parent is merged on the source branch and contains the same Pick-to: target as the current target branch for the child change. Following a waiting period, the bot should fall back to walking the relation chain to find the first parent which exists on the target branch to ensure that the cherry pick occurs, even if it breaks the relation chain after a reasonable waiting period.