Select server topology ancestors from the same CDN as the base server

[zrhoffman]

What does this PR (Pull Request) do?

• This PR fixes TO /servers/{hostname}/update_status parentRevalPending is not CDN-specific #5505 by making parentRevalPending be CDN-specific

Which Traffic Control components are affected by this PR?

• Traffic Ops

What is the best way to verify this PR?

1. Start CDN in a Box
2. Create an invalidation request for the demo1 Delivery Service
3. Notice that https://trafficportal.infra.ciab.test/api/4.0/servers/mid-01/update_status says parent_pending = true
4. Set the CDN ID of mid-01 in the database:

   <<'SQL' docker-compose exec -T trafficops bash -c 'PGUSER=$DB_USER PGPASSWORD=$DB_USER_PASS PGHOST=$DB_SERVER PGDATABASE=$DB_NAME psql'
   UPDATE "server" set cdn_id = 1 WHERE host_name = 'mid-02'
   SQL

5. Notice that https://trafficportal.infra.ciab.test/api/4.0/servers/mid-01/update_status says parent_pending = false

If this is a bug fix, what versions of Traffic Control are affected?

• master (1cd5046)
• 5.0.0
• 5.0.x branch

The following criteria are ALL met by this PR

• This PR includes tests OR I have explained why tests are unnecessary
• Bugfix, no documentation is necessary
• This PR includes an update to CHANGELOG.md
• This PR includes any and all required license headers
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

Additional Information

[ocket8888]

I still can't reproduce this. At step 3 of the verification, I see "parent_pending": false.

[zrhoffman]

I still can't reproduce this. At step 3 of the verification, I see "parent_pending": false.

You could just set update_pending to true for mid-02 in the servers table

[ocket8888]

That did it. Probably explains why I couldn't reproduce the issue in the first place; I didn't know you needed to queue updates after creating the invalidation job.

[ocket8888]

Confirmed this fixes the issue.