Ensure lockfile target exists before injecting a dependency to it.

[kaos]

Fixes #17343

Example warning message when the _lockfiles target is being shadowed:

09:25:43.12 [WARN] The synthetic lockfile target for 3rdparty/python/user_reqs.lock is being shadowed by the python_requirements target 3rdparty/python:python-default.

There will not be any dependency to the lockfile.

Resolve by either renaming the shadowing target, the resolve 'python-default' or moving the target or the lockfile to another directory.

[asherf]

@Eric-Arellano @stuhood ping

[Eric-Arellano]

Hm, does this mean that if you have your repo in the wrong shape that we simply don't add the dependency at all on lockfile targets? That also seems broken.

What about your earlier idea to instead use an unambigous target name? If that's too hard to performantely check which target names already exist, then use some special value extremely unlikely to be claimed, like __resolve_my_resolve__

[kaos]

What about your earlier idea to instead use an unambigous target name?

The issue was that we don't know the other targets at the time we need to pick our target name. Going with a very obtruse name to avoid a potential name collision feels.. not great. This fix avoids a real issue at the cost of not getting the benefit of this new feature, with the easy fix of adjusting either the conflicting target's name or the name of the resolve, or moving either the lockfile or the conflicting target to another path. (just to give a hint that there are more than one way to work around the issue presented in #17343)

[Eric-Arellano]

Maybe we log then a warning about the collision? And add this edge case to the help message?

On that note, would be good to use a rule_helper for DRY

[kaos]

@Eric-Arellano @stuhood ping. I think we may want to pick this to 2.15.x as well.

[kaos]

@stuhood I'd like to rebase #17451 on top of this one to avoid merge conflicts for the synthetic target tests (that is, before I start writing more tests for synth targets for that PR there's changes in here I'd like to make use of)

[stuhood]

Thank you.

This problem seems loosely related to the idea of "hygienic macros": i.e., that a macro should be able to define anonymous variables which can't collide with or pollute the original namespace. But I don't know how to do that and still have consumers later depend-on/find them... maybe by having the request for the syntethic target use something other than its name/address?

In any case: shipping to unblock the fix.