make deprecation origin addr as precise as possible

[DanielMSchmidt]

Fixes #

Target Release

1.15.x

Rollback Plan

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

CHANGELOG entry

• This change is user-facing and I added a changelog entry.
• This change is not user-facing.

[jbardin]

I think what you had might have been optimal already. When talking about use of deprecated attributes, it's based on the resource schema and what is written in the configuration. Configuration is only written as unexpanded blocks, and the source of deprecated values can't change based on individual instances because the resource name and schema is always the same.

[DanielMSchmidt]

@jbardin it would make sense to use at least config addresses as the basis for the extra info string, right?

[jbardin]

Oh! I see what you mean. I was reading that as if you had config addresses and wanted to refine them to instances. Yeah, using ConfigResource matches most closely to how a user would be thinking about the config location, and at least for resources we have addr.InModule for that. The module call will take a little more fiddling to get rid of the instance part, but we should probably do it there for consistency, since the deprecation doesn't come from only a single instance, but the definition in the config.

(and just a style note, %s and %q use the fmt.Stringer interface, so you don't need the String() call on all the arguments)