Services: Make supported version check optional

[mikemilano]

Currently, lando start / lando rebuild will fail, warning the user if a service version defined does not exist in the service.config.supported array.

The dependency on valid versions maintained in Lando for images that are maintained by a 3rd party introduce dependencies that may justify omitting the version restriction altogether.

The concern was introduced with the images maintained by platform.sh as keeping the supported versions list in sync could become cumbersome and error prone.

This dependency between the 2 contexts impacts Platform.sh and Lando in the following ways:

• Platform must notify Lando when an image version is added or removed
• Lando must update codebase and release a production build promptly
• There is potential for the 2 sides to get out of sync

The consequences to allowing supported versions to be based on if the image or tag exist are:

• There's no way for us to designate specific versions as officially supported
• The burden of assuring new images are compatible falls on the upstream team

Getting rid of supported versions is not an option, but it does make sense to support the case to bypass the version restriction for images maintained by 3rd parties in partnership with Lando. (i.e. upstream actually plans and accounts for the downstream integration)

Proposal

Allow the omission of config.supported in service definitions.

Services without config.supported items will be handled as follows:

• The initial build check that would typically cause it to fail will be bypassed
• Logic will be added to gracefully fail the build if the image or tag does not exist
• Initially this will only be allowed to upstreams we trust are maintaining images in partnership with Lando

Alternatively, we could add an explicit key to bypass version check instead of relying on the omission of values.

[mikemilano]

@pirog I added you to the ticket for the decision points:

1. Do you prefer the version check bypass be indicated by a designated config var, or simply the omission of config.supported

2. If it's a go, then we just need to prioritize and schedule it.

[pirog]

@mikemilano so i think we want an explicit key to disabled the supported check. The reason why i think this would be better than omission is:

1. If you currently omit supported the default is set to ['custom']. It's unclear to me whether changing this default would be a breaking API change or not so probably best to avoid mucking with it altogether.
2. Generally, and in most cases, we assume the service will be required to have some sort of supported version list. So i think disabling a usual requirement in favor of an edge case is best done in an explicit way vs an omission.

I queued this up as part of our Alpha psh sprint. I also think we should remove supported for all the platform.sh services that currently define it primarily to avoid future confusion.

What do you think?

[pirog]

@mikemilano alright this is merged into master now!