Provide dns Message and EDNSMessage constructors which accept FlagConstants and ValueConstants

	@wallrj reported
Trac ID	trac#6778
Type	enhancement
Created	2013-10-09 14:09:00Z

In ticket:5675#comment:16 exarkun wrote:

  1. Earlier you mentioned an idea about improving the handling of these
  numerous flags.  I think that's a good idea to pursue.  Consider this
  idea (not necessarily for this ticket, since making these APIs private
  means we have plenty of time to improve them with follow-up work) -
  `__init__` should accept a `FlagConstant` collapsing as many of these
  flags as possible (looks like there are 8 parameters that would all
  combine into 1) into a single value.  We could also think about whether
  `opCode`, `rCode`, and `ednsVersion` merit more special handling
  (perhaps a `Values` constant instead of `int`) and For compatibility,
  `_EDNSMessage` can also:

    1. provide an alternate constructor with a signature more like its
    current `__init__` signature - this would be an API more like a
    drop-in replacement for `Message.__init__`.  This can also include
    whatever extra safety checks seem useful to help developers avoid
    subtle mistakes (though hopefully we can also encourage them to switch
    to the nicer API).

trac-id__6778 6778
type__enhancement enhancement
reporter__rwall rwall
priority__normal normal
milestone__ 
branch__ 
branch_author__ 
status__new new
resolution__None None
component__names names
keywords__ 
time__1381327740000000 1381327740000000
changetime__1381327740000000 1381327740000000
version__None None
owner__ 

Locate the Message and EDNSMessage constructors and the FlagConstants and ValueConstants definitions, then read the API discussion quoted from ticket 5675. Done means the constructors accept the consolidated constants while EDNSMessage retains a compatible alternate constructor and appropriate safety checks.