Reduce TM dependency on CRConfig

[rawlinp]

Do not use CRConfig data when the same data already exists in the
TMConfig. For data that TM needs but doesn't exist in TMConfig, add it
to TMConfig. This way, TM only uses data in the TMConfig and can become
simply a shuttle for the CRConfig without actually using any CRConfig
data.

Closes: #6512
Related: #1739
Related: #5367

---

Which Traffic Control components are affected by this PR?

• Documentation
• Traffic Monitor
• Traffic Ops

What is the best way to verify this PR?

Ensure the GHA tests pass. Take a snapshot of a CDN before this change, then take a snapshot after this change and compare the TMConfig snapshot to see the newly added fields. Compare the newly added fields to the corresponding data in the CRConfig snapshot (they should be the same). Run TM with the new snapshot and ensure it still polls and functions normally.

PR submission checklist

• This PR has tests
• This PR has documentation
• This PR has a CHANGELOG.md entry
• This PR DOES NOT FIX A SERIOUS SECURITY VULNERABILITY (see the Apache Software Foundation's security guidelines for details)

[rawlinp]

Rebased to resolve changelog merge conflicts.

[ocket8888]

I only made docs comments for the first version I encountered to avoid being overly repetitive. On that note: shouldn't these changes be made only to APIv4? I know the Snapshots have historically been unversioned, and "monitoring dot JSON" has always been a quasi-part of that snapshot, but it's used in TO Go client call signatures, so won't changing that be a breaking compile-time change?

[rawlinp]

shouldn't these changes be made only to APIv4?

I don't see why it can't be made to all versions, since this is non-breaking to the expected JSON formatting because it only adds new fields and doesn't change data types or rename existing fields.

As far as the TO client goes, this does technically make a breaking change to the TrafficServer and LegacyTrafficServer structs by changing the type of DeliveryServices from []tsdeliveryService to []TSDeliveryService, but the odds that any external client is actually using that field, when it wasn't even populated in the monitoring.json snapshot in the first place, seem drastically low. Therefore, I felt that is an OK breaking change.

[ocket8888]

shouldn't these changes be made only to APIv4?

I don't see why it can't be made to all versions, since this is non-breaking to the expected JSON formatting because it only adds new fields and doesn't change data types or rename existing fields.

As far as the TO client goes, this does technically make a breaking change to the TrafficServer and LegacyTrafficServer structs by changing the type of DeliveryServices from []tsdeliveryService to []TSDeliveryService, but the odds that any external client is actually using that field, when it wasn't even populated in the monitoring.json snapshot in the first place, seem drastically low. Therefore, I felt that is an OK breaking change.

That's fine with me, I suppose. It's not like we haven't broken that call signature in the recent past anyway - which I think was actually my doing. The docs pages for monitoring and Snapshots should really have a disclaimer about their instability. Right now monitoring has nothing and I think the Snapshots page has a "Caution" thing I put in saying how basically the guy writing the docs couldn't figure out a definite "shape" for that endpoint's data, so it needed updates from people who did. Should just be changed to "this, historically, just can't be relied upon to respect its versioning in the API". Not that I think you need to do that in this PR - although you're welcome to if you want.

And, of course, I'll then need you to tank aggro when @rob05c finds out about it.

[rawlinp]

I'll tank if you heal 😄

IMO all snapshots are unversioned because they should be handled as raw JSON data to which we can freely add new fields without making breaking changes. Plus, the fact that they're read-only means they're immune to round-trip data loss which could occur if a client were to drop unknown fields from a GET then make a PUT/POST without those fields.

[ocket8888]

I think you need to rebase this on master to get the CiaB CI to pass nvm - that won't help yet

[zrhoffman]

I think you need to rebase this on master to get the CiaB CI to pass nvm - that won't help yet

fixed in #6678

[rawlinp]

ERROR: for to_server  (<Service: to_server>, 'Build failed')
Service 'to_server' failed to build : Build failed
Error: Process completed with exit code 1.

However, this builds fine for me locally using docker... I can't really tell why it's failing here.