Cherry-pick bot does not wait for parents if the first parent is invalid

In the event that a relation chain is integrated together, but one change in the chain is not staged with the rest of the chain, it is possible that any changes higher in the chain than the unmerged one will skip more than just the missing change to find a parent.

This occurs under heavy load when cherry-picks for changes lower on the relation chain on the target branch do not yet exist when walking the relation chain for higher changes.

Essentially, this is due to a race condition, since all cherry-pick processes are performed concurrently. The expectation is that an immediate parent should exist on the source branch, and it should target the same branch that the current request is targeting. If this is the case, the bot waits for the expected cherry-pick to be created and all is well. But, if the immediate parent is not merged on the source branch, today's logic simply walks through the relation chain and checks to see if each possible parent exists on the target branch. While fine in theory, the race condition here means that in practice, some or even none of the expected parents will exist on the target branch when testing for them.

To correct this behavior, a timed gate should be introduced for each possible merged parent in the chain. If a parent does not exist yet on the target branch, check back in 15 minutes. If it still doesn't exist, move on and try the next parent in the chain. Repeat this process until a parent is found or all parents are exhausted, defaulting to the target branch HEAD.