Dynamic option numbering desired.

As we make transports and protocols pluggable, its likely that the framework will not know the option numbers apriori, and unless we want to get into managing the identifiers for option numbers, we should contemplate a mechanism where by option ids are "registered" dynamically, allowing applications to select options using a string. (The only other option is to create and manage a registry, which is a PITA and not scalable.)

I am proposing an API like this:

// gets the same value if option string is already known.  can return NNG_ENOMEM
// No unregister; but nng_fini() cleans them all up, hence protocols and transports
// need watch these.  Knowing the scope allows us to avoid passing transport options
// to protocols, and vice versa.  (Segregate by ID.)  (XXX: maybe we should register
// other information to help with discovery?)
enum { NNI_OPTION_SCOPE_PROTO, NNI_OPTION_SCOPE_TRANSPORT };
int nni_option_register(int *valuep, int scope, const char *name);

// Public API (nng.h)
int nng_option_lookup(int *valuep, const char *name);

Providers and transports will be expected to use names that are specific to them to avoid collisions by scoping the option names with a "/". E.g. a TCP option could be "TCP/NoDelay". Names without a "/" are assumed to be common, socked scoped.

Using a two step lookup will allow the hot code paths to just use integers like they always have done.

nanomsg / nng

Dynamic option numbering desired. #72