Error handling

[BasileiosKal]

Implicitly handle errors form the utility sub-routines in the core operations + address point B from #246

[BasileiosKal]

Updated the PR with the following

• Introduced ABORT (like in h2c). An operation will ABORT if some of the Precoditions are not met. Any operation calling a function that ABORTed will also ABORT.
• If expand_message ABORTs (which it may), hash_to_scalar will also ABORT, so no need for checking explicitly its result (or require expand_len to be defined in a way that will not cause expand_message to fail, which may not always be possible).
• return INVALID is used for errors in the Deserialization/Procedure (like getting an invalid signature or deserializing a malformed proof). A subroutine's INVALID result is explicitly handled by the calling operation.
• Updated hash_to_scalar and create_generators to NOT check for 0, duplicates etc.

IMO this gives the more readable result.

[christianpaquin]

Improves readability

[andrewwhitehead]

I believe this would be checked by serialize?

[BasileiosKal]

Yes. Iv added these checks here to ABORT instead of returning INVALID (which we would have to do if we were relying on serialize for the checks).

That way we don't have to check the result of calculate_challenge and calculate_domain in the core operations.

[BasileiosKal]

Breaking Changes

1. In hash_to_scalar removed the counter
2. In create_generators step 3, changed I2OSP(i, 4) to I2OSP(i, 8)

("1." is because I removed the checks for 0 and "2." is to align the max number of messages with the max number of generators)

[tplooker]

Ready for merge, subject to resolving the conflicts.