Improve ergonomics of experimental feature acknowledgement

[wmorgan]

In order to use the Consul namer, you have to refer to it as io.l5d.experimental.consul in the namer config block, but io.l5d.consul in the dtab. (This may also be the case for other experimental namers.)

This is somewhat confusing, especially since non-experimental namers are matched in these two sections. At a minimum, this discrepancy should be documented.

[olix0r]

We want a way to introduce new and unproven features for evaluation. We'd like to require some form of acknowledgement from the user to enable these features so that it's easy to distinguish these modules. Furthermore, this should be accomplished in a way so that users are not required to alter their configurations when the features are no longer considered experimental.

Currently, modules such as the consul namer have experimental in their names, such as io.l5d.experimental.consul and a default prefix like io.l5d.consul. The module name includes experimental as a form of acknowledgement, but the prefix was intended to be stable so that it would not have to change once the module is no longer experimental. This is confusing, and isn't as future-proof as we'd like

This should be fixed as follows:

• module names are no longer placed in an 'experimental' namespace. io.l5d.experimental.consul becomes io.l5d.consul
• modules support an optionally-specified experimental field. A module may fail to initialize if this field is not specified.

While we're here, we should consider experimental features within a module. We have a few options in how to structure this:

kind: io.l5d.consul
experimental: true

kind: io.l5d.consul
experimentalSomeFeature: true

Or, we could allow experimental to be either boolean or a feature map

kind: io.l5d.consul
experimental: true

kind: io.l5d.consul
experimental:
  someFeature: true

[adleong]

Fixed in https://github.com/BuoyantIO/linkerd/releases/tag/0.6.0