Include password hashing function into definitions

[michaelklishin]

…and use it during definitions import.

The idea was brought up in #116 but in a different context. It's not so much about those upgrading from 3.5.x — we have a documented procedure for them — but for those who will use a non-default function on 3.6.0+ and perform imports.

[michaelklishin]

Note: if we can make upgrading via definitions import smooth for 3.5.x users, we definitely should.

[michaelklishin]

Sorry, I'm not being specific enough: the definitions exported from 3.5.x will not have a hashing module field (unless we do another 3.5.x release, which is unlikely). So we need to be careful about what we do in that case:

• Assume that we upgrade from 3.5.x and record hashing module as MD5
• Assume that we upgrade from 3.6.0 and record hashing module as SHA-256

If there is no way to tell 3.5.x definitions from 3.6.0, we should do the latter and continue advising 3.5.x users to temporarily set hashing function to MD5 first.

@hairyhum let me know if the above isn't clear.

[michaelklishin]

Someone suggests that if a hashing module value is missing, we should use the server default. Which makes total sense :)

[hairyhum]

Someone suggests that if a hashing module value is missing, we should use the server default. Which makes total sense :)

So 3.5.x users will still have to set it to MD5 first?

[michaelklishin]

Unless we can tell a JSON export file produced by 3.5.7 from the one produced by 3.6.0, yes.

[noahhaon]

This won't help existing users < 3.6.0, however it would be a great idea to add a version to your definition exports (and to go one further, HTTP headers in your API responses) such that special cases like this could be more easily handled in the future.

[michaelklishin]

That's the point: we need to make sure the same issue doesn't pop up in the future.

[michaelklishin]

@hairyhum's solution in #119 works well. Manual testing with 3.4.x and 3.5.x definitions was successful, 4 test suites pass.

[michaelklishin]

Because definitions include RabbitMQ version we managed to cover versions from 3.0.0 through 3.5.7 and 3.6.0. Good job, @hairyhum.