Introduce new errors for unsupported driver behaviors

[jedevc]

Around discussion in #1186, a few issues with buildx drivers came up. These scenarios are unsupported, but the user isn't warned, for example:

• The kubernetes endpoint cli arg will be overwritten internally, so the user's specification is ignored
• Appending a new node to a builder with a different driver than the original is unsupported (and atm will overwrite the previous builder's driver)
• Creating builders with the same name as context builders gives a warning, but appending and deleting doesn't.

This PR should resolve the above issues, and provide a more helpful local debugging experience.

[jedevc]

Have added another check, to error on attempting to edit nodes with --node, while including --driver-opt (which are otherwise silently discarded).

[crazy-max]

LGTM, PTAL @tonistiigi

[tonistiigi]

For the node update, if we are allowing flags then I don't see a reason why we would error on driveropt/config.

For the mixed drivers, looks like an oversight as well. Although this one is harder to fix. I don't see a specific reason why this should not be allowed. All the driver instances are passed separately to the build function. They do not need to be of the same type there.

[jedevc]

For the node update, if we are allowing flags then I don't see a reason why we would error on driveropt/config.

I think at the very least we should warn here - we allow the --driver-opt flag on a node update, but it will be silently discarded. The flag has to be accepted here since it's the same create subcommand that we use to create drivers in the first place.

Will update the PR to do this.

For the mixed drivers, looks like an oversight as well. Although this one is harder to fix. I don't see a specific reason why this should not be allowed. All the driver instances are passed separately to the build function. They do not need to be of the same type there.

True. However, the way we store the drivers in config makes this harder to do - the driver is attached to the NodeGroup, so to do this we'd need to push down the driver config into each individual Node, not quite sure what implications that would have, but seems like an interesting possibility 👀