WIP: use data driven approach when interacting with datatypes

[Pat-pGuo]

For review:

• implement leaf datatypes
• implement structural datatypes
• make dictionary.Attribute.encode() and decode() datatype agnostic
• make packet.DecodePacket() datatype agnostic
• existing unittests fixes

Work in progress:

[alandekok]

I don't understand what the "print" functions are supposed to do here.

The requirement for print is "print this value to an ASCII string". The class also needs a related parse routine. which takes an ASCII string, and returns a python structure / dict containing the attribute

This functionality lets us do the following tests:

decode HEX -> python stuff
print python stuff - ASCII

Human reads the ASCII and manually checks it agains the HEX to be sure it's OK.

We can then do

parse ASCII -> python stuff
encode python stuff -> HEX

which should then result in the same HEX output as above.

Once the unit tests have been verified manually (or copied from FreeRADIUS), the tests can be run in CI. The tests then ensure that:

a) the decoder can handle the packets correctly
b) the ASCII output doesn't change
c) the parser can read ASCII output
d) the encoder can encode things correctly

[Pat-pGuo]

So yes, the print function is returning an ASCII string. It just so happens that Pyrad has been storing these datatypes as strings, thus I simply return the value (which is an ASCII string).

[alandekok]

Is there an IPv4 prefix type?

[Pat-pGuo]

As per discussions with @arr2036, that's planned for the next PR (which will contain all of the datatypes not currently in Pyrad). This PR is for restructuring existing datatypes.