feat: add aliasfix to fix migrated import paths

[codyoss]

This will assist us in the migration effort and is also a tool our users can use.
The tool is allowlisted to only migrate specific imports, and only if we have
made a configuration change to say the code has been migrated.

[codyoss]

Once merged in a future PR, it may be a good idea to move the mapping file elsewhere or make it public so gapicgen can rely on it too. That way the tools can stay in-sync.

[noahdietz]

FWIW, the GAPIC generator already does this in that if we give it an "import path override" for the protos its generating, it will know to generate request/response/stub types using the "overridden" import path. This of course does not help with manual clients.

I do realize though that there has to be a time where we generate the stubs in google-cloud-go without changing the type in the signature for the GAPIC, while we do the alias/release dance. Perhaps we need to toggle when the GAPIC generator is made aware of he import path override e.g. decouple it from configuring gapicgen to generate stubs in google-cloud-go. Right now it is coupled (see storage) in that if we want to provide an override, the GAPIC will respect it rather than deferring to go-genproto still.

[codyoss]

@noahdietz This is supposed to be more of an equivalent to go fix. I fully intend for us to leverage the generator override. This is for updating existing code that references go-genproto.

For example:

• Users can run this command in their local code to fixup all import paths automatically.
• We can use this in the samples repo to mass update samples to use new type locations.

[codyoss]

I do realize though that there has to be a time where we generate the stubs in google-cloud-go without changing the type in the signature for the GAPIC, while we do the alias/release dance. Perhaps we need to toggle when the GAPIC generator is made aware of he import path override e.g. decouple it from configuring gapicgen to generate stubs in google-cloud-go. Right now it is coupled (see storage) in that if we want to provide an override, the GAPIC will respect it rather than deferring to go-genproto still.

You are right. We may be able to accomplish them by just having a toggle in gapicgen to regen in both locations in two different invocations of protoc

[noahdietz]

@noahdietz This is supposed to be more of an equivalent to go fix. I fully intend for us to leverage the generator override. This is for updating existing code that references go-genproto.

For example:

• Users can run this command in their local code to fixup all import paths automatically.
• We can use this in the samples repo to mass update samples to use new type locations.

Oh! cool! awesome.