Expose Sha256 algorithm to lua api

[chmodsayshello]

This is a pull request allowing the sha225 algorithm that already is in minetest's code to be used by mods, which are currently limited to just sha1. This allows mods to hash a given set of data in a more secure way if needed.

This PR Ready for Review.

How to test

1. Clone my branch and compile minetest
2. Call minetest.sha256 as a mod, and log the result
3. Use an external tool/webpage like this to verify the hash is correct.

[wsor4035]

just a thought as a modder/thinking of the api, as these options are added, potentially more in the future, it seems this would pollute to a degree the minetest api namespace, maybe it would be better to have something like minetest.encode(method, ...) similar to minetest.compress? with the previous said, of course minetest.sha1 will have to exist for backwards compat, however that could be depreciated and aliased to a new function.

alternatively:
minetest.encode.TYPE

[appgurueu]

just a thought as a modder/thinking of the api, as these options are added, potentially more in the future, it seems this would pollute to a degree the minetest api namespace, maybe it would be better to have something like minetest.encode(method, ...) similar to minetest.compress? with the previous said, of course minetest.sha1 will have to exist for backwards compat, however that could be depreciated and aliased to a new function.

alternatively: minetest.encode.TYPE

The latter is the better suggestion, IMO.

• It means minetest.hash.this_does_not_exist(...) will result in an attempt to call a nil value (otherwise we'd have to implement erroring on invalid values ourselves).
• Modders can also check for the existence of a certain method conveniently - just minetest.hash.method (otherwise we'd have to add some feature flags or similar).
• Editor tooling will also understand minetest.hash.blah better than minetest.hash("blah", ...).
• It also makes the intent (we're choosing an algorithm here, not passing some string data) clearer, IMO.

(By the way, it should be minetest.hash or similar. These are "secure hashing" algorithms.)

[sfan5]

IMO there's no reason or usecase for sha224 and we shouldn't expose it. If we have leftover code we should rather go and remove it.

[wsor4035]

The latter is the better suggestion, IMO.

• It means minetest.hash.this_does_not_exist(...) will result in an attempt to call a nil value (otherwise we'd have to implement erroring on invalid values ourselves).
• Modders can also check for the existence of a certain method conveniently - just minetest.hash.method (otherwise we'd have to add some feature flags or similar).
• Editor tooling will also understand minetest.hash.blah better than minetest.hash("blah", ...).
• It also makes the intent (we're choosing an algorithm here, not passing some string data) clearer, IMO.

(By the way, it should be minetest.hash or similar. These are "secure hashing" algorithms.)

while i agree, mainly suggested it that way to keep consistency with minetest.compress

[chmodsayshello]

I'll depend on #14265 as it's likely to be merged before this (that one doesn't add anything, was created by a core dev etc, while this still has no roadmap approval), and that way I'll be able to update the PR for it early...

[Zughy]

@chmodsayshello the PR you mentioned has been merged, feel free to proceed as discussed :)

[sfan5]

If md is NULL, the digest is placed
in a static array. Note: setting md to NULL is not thread safe.

[sfan5]

please keep this space