snmp v3 fixes

[micdmy]

Hi. that's me again :-)
I needed v3 support in my app, but when i tried to use it only md5 and sha1 worked for me (it was before ver. 04.11 :-) ).
So i made some fixes, and finally i get to the state where all 31 combinations of Auth and Priv worked.
I also make a server(s) to test different v3 Auth and Priv, feel free to use it:
https://github.com/micdmy/snmp-test-server

I tested my solution against net-snmp 5.9 agent with all Auth/Priv combinations.
I also created tweaked net-snmp that uses reeder's method instead blumenthal, because i added support for both of these key extension method to your lib.

What i fixed and why:

• I started with the same hmac len which was hardcoded to 12. But i see that you already fixed that in 0.4.11. So i just take you solution. I just left use of sign_to_vec(), which i think nicer (my opinion).
• Then i noted that in parse func, authoritative state was not updated when i connected to net-snmp server. Maybe it works with different agents. I don't know. I fixed that
• I re-exported openssl, so crate that uses snmp2 could use the same openssl ver as your lib.
  I needed to call openssl functions to enable legacy provider for DES support.
• I added key extension methods (reeder and blumenthal) which are needed in 5 particular Auth/Prov combinations where Auth hasher is too short for Priv key generation. Now you can create Security with '.with_key_extension_method(...).
  If you don't these combinations are not supported and you get new error kind when doing session .init()
  blumenthal and reeder are kind of non-standard (according to some rfc i don't remember), so i decided that default Security have them disabled. It also doesn't break the previous behaviour and library API.
• I also added fn to the session that checks if changing key extension method would help connecting and it returns next key extension method to try. I use in my app to implement fallback mechanism.
• I returned raw error instead of unwrap() on encrypt() call. I believe that panicking should only be used where we are 100%-ish sure it wont happen. And encrypt() easily fails i.e. if you dont have DES support enabled in openssl. That happened to me.

Last thing. Not related to v3 support but async session.
In my app i create dozens of sessions to many hosts in async fasion.
Because send, recv are stack - allocated I get stack overflow. This happens because rust holds the stack across awaits points.
So i added feature 'heap_buffers' to allocate buffers as Box<[u8]>. It helps with stack overflow.

I can provide you with minimal example to reproduce the stack overflow if you interested.

Best regards,
Michał

[divi255]

thanks again. it's a pretty big PR so I gonna test it within a few days this week