Keep the sdk version inline with the bridge

[iwahbe]

This removes the --kind=sdk option from the tool.

We already have functionality to bring the pkg+sdk version in all places up to what the bridge requires.

Fixes #184

[t0yv0]

I'm a little confused here as it removes the ability to update SDK completely. Is that too much? Does it update the SDK as part of the "bridge" or "all" update? perhaps just dropping that from "all" suffices to not run it until asked to?

[iwahbe]

I thought about dropping sdk from all, but leaving it as an explicit option. I couldn't think of a situation where we want to upgrade the SDK (which only goes to latest) to differ from the bridge version, or where we would recommend downstream users to do so.

It's not a safe upgrade, since sometimes pu/pkg makes breaking changes and the bridge needs to adjust. upgrade-provider --kind=sdk may fail, even when every party adheres to their contract. upgrade-provider --kind=bridge should not fail if every sub-system works as expected.

[t0yv0]

Hm, that's reasonable but how about upgrading native providers that have no bridge? I guess we can deal with that when we need to. I was also thinking to consider to make it triple-certain, basically "ensure", the invariant that {pkg,sdk} dependency is strictly never ahead (or is equal) to the bridge's {pkg,sdk} dependency. But this automation can get in the way of mowing down custom go.mod setups.

[iwahbe]

Hm, that's reasonable but how about upgrading native providers that have no bridge? I guess we can deal with that when we need to.

This tool really doesn't work on native providers (calling make tfgen, etc). They don't have a standardized layout, so can't have a standardized upgrade process.

I was also thinking to consider to make it triple-certain, basically "ensure", the invariant that {pkg,sdk} dependency is strictly never ahead (or is equal) to the bridge's {pkg,sdk} dependency. But this automation can get in the way of mowing down custom go.mod setups.

I don't think that is necessary right now. If the only thing that upgrades pulumi/{pkg,sdk} is this tool, we should get the versions that we expect. If we find version mismatches, then we can re-asses on an explicit check.