AaaP follow-up: Handling of legacy remotes & CAS/Artifact services

Background

With !1292 (merged) landing, the way buildstream caches & defines an artifact has changed, moving from a reference based service. As such existing artifact remotes need to be updated to support this change and then repopulated with proto based artifacts. (Not supporting the migration of artifacts was discussed in the proposal https://mail.gnome.org/archives/buildstream-list/2019-January/msg00013.html)

When trying to create the user story of what happens when somebody using bst that has AaaP hits a remote that hasn't been updated to support it no direct conclusion was made (!1292 (comment 169300280)). As such at the current time of writing a user running in interactive mode will hit an error on each attempted artifact pull/push, with the quickest remedy being to disable the 'old' remote url until it has been updated. In the linked discussion it shows some of the challenges that have arisen when trying to improve the user experience here whilst still keeping the casremote class 'Artifact' free.

Task description

Decide what the user story should be if a user is unable to push/pull to a remote due to it not being compatible. What would the default behaviour be, should this be user configurable?
How does buildbox-casd help with separation of remote communication and CAS/Artifact detangling out of buildstream. Does something stopgap need to be put inplace in the meantime?

Edited May 15, 2019 by Tom Pollard