[Discussion] Action Versioning

This is to discuss the new feature, "action versioning".

It originates from the need for invokers to fetch a specific version of the action.
After a user invokes an action and before an invoker receives the activation message if the user updates the action, the version of action is updated, but the invoker still tries to fetch action with old revision. At this point, `Boxed Error` happens.

```
[2019-07-19T08:58:14.747Z] [ERROR] [#tid_ec27fe8f4334dc324422f95769477660] [CouchDbRestStore] [GET] 'whisk_local_whisks' internal error, doc: 'id: guest/noop, rev: 1-5f1211b4597236ee3dfe504d5db6ab59', failure: 'Boxed Error' [marker:database_getDocument_error:434:40]
```
Generally, it does not happen under a normal situation as activation passing is faster than action update, but it can happen in some cases.

CouchDB has the functionality to fetch data with a specific revision. But this feature is not being used by OpenWhisk.
https://docs.couchdb.org/en/stable/api/document/common.html#obtaining-a-specific-revision

One limitation is, old revision of data can be removed by the compaction.
https://github.com/apache/couchdb-fauxton/issues/1069
https://stackoverflow.com/questions/9730299/are-old-data-accessible-in-couchdb

Also, other `ArtifactStores` such as `CosmosDBArtifactStore` may not have such a versioning functionality.
So it would be great for OpenWhisk itself to have the versioning feature.

AWS Lambda also supports this kind of versioning feature at the platform level.

I think the versioning feature can enable many deployment scenarios such as blue-green, canary deployment and so on. Such deployment methods are already supported in K8S with Istio.

Similarly, we can imagine the scenario that we assign two different versions of an action to one execution URL, and control the routing ratio between them. This would be useful for users to test their new version of the action with the real traffic.

Currently, OpenWhisk has a `version` field, but mostly it defers the versioning to users.
Above mentioned is just one use case. I believe users can benefit from it in many directions.

So it would be great to list up requirements and use cases of this feature.

Start by reviewing the issue's action-update race, ArtifactStore limitations, and the listed deployment use cases. Define the requirements and use cases for OpenWhisk-level action versioning, including behavior when old revisions are unavailable and how routing between versions should work; no implementation entry point or test is identified in the issue.

Written by the indexing model from the issue text.