[Nbd] More efficient treatment of experimental protocol extensions

[Alex Bligh <alex@...872...>]

I have a proposal for the more efficient treatment of experimental
protocol extensions. This primarily concerns doc/proto.md, but
potentially affects code too.

At present the experimental protocol extensions are described in
'experimental extensions' at the bottom of the document in master.
This causes some issues:

* The document is longer for those that don't want to read about
  protocol extensions.

* The document is more volatile than it might be, as each change
  to an experimental extension requires a change to proto.md
  and these carry a high risk of conflict.

* The body of the document inevitably ends up referring to
  the experimental extensions, which is a pain, as you only
  should need to know about the experimental extensions if you
  implement them.

* Worst of all, after all the careful wordsmithing of experimental
  extensions, they then need to be promoted into the main document,
  (when they cease to be experimental) which requires more wordsmithing.

My proposal is as follows:

* Experimental extensions do not appear in proto.md in master at all
  EXCEPT for reservation of codes (e.g. "NBD_OPT_FOOBAR (42) - reserved
  for experimental FOOBAR extension").

* Experimental extensions themselves live in a git branch. This carries
  the wording of the extension as it would be if it were incorporated
  in to the main document. Part of the change set removes the
  above text and says "NBD_OPT_FOOBAR (42) - see FOOBAR" or descibes
  it in place).

* The text re NBD_OPT_FOOBAR above has a link in proto.md (in master)
  to the relevant branch's proto.md, so you can simply click through
  to find it.

* Merging (and thus promoting to non-experimental) an extension is
  as simple as merging the branches.

* The extension branches could then also contain code to implement
  the extension on nbd-server.c and nbd-client.c as appropriate.

* This means the documentation for an experimental feature and the
  code to implement it can be kept together, and can be merged easily.
  This should reduce proposed changes to master's proto.md, and
  it means resolving conflicts is the job of those writing the
  extension (i.e. they need to effectively rebase their patches
  on master).


-- 
Alex Bligh