Add integer support

[LivInTheLookingGlass]

This pull request adds the ability to encode integers in Base58. If it gets merged with #11, I will need an additional commit to add type hinting.

[keis]

Added some general comments to the code but could you explain a bit what your use case for this is? Are you trying to make this match some other implementation of base58 of integers?

there's a slight difference between
b58encode(struct.pack('>I', X)) and int_to_b58(X) which I would like to avoid.

[keis]

I would prefer to have these names symmetrical with the ones already existing, so something like b58encode_int and b68decode_int

[LivInTheLookingGlass]

That makes sense. I can revise that.

[keis]

Because internally the other encoders convert to a number before encoding to base58 this should look exactly the same as the L57-L60 in b58encode

[LivInTheLookingGlass]

Mostly its that I find myself encoding smaller things in base58, like timestamps. Its also useful for people who use this sort of thing as a link shortener, as you usually won't need to go to very large numbers for a long while.

[keis]

Ok, I see. So if you're going to keep reasonable small numbers I think doing b58encode(struct.pack(...)) would be the most straight forward route. I think it would make sense to add an alias for this in the module if that fits what you're doing.

For bigger numbers there is (5).to_bytes(10, 'big') at least in py3 that does almost the same thing.

This does enforce a fixed size of the messages but I don't think that's a big issue and because this module uses the bitcoin leading-0 compressions even less so, WDYT?

[LivInTheLookingGlass]

I'm reluctant to use the struct.pack route because it would both limit the size you can encode and produce extra, unnecessary characters to process.

I did do a bit of benchmarking on it, and solutions like that ended up taking ~2x as long. So while this doesn't work quite the way the others do, it is the faster solution in this specific case.

[keis]

So on a closer look the only difference seems to be when leading zeros are in play, which of course does not make sense for integers. So that's all good.

All things being the same these methods should already exists and could be extracted as submethods from the already existing ones. There is some slight difference like the use of divmod which I think will be more performant.

[LivInTheLookingGlass]

I'll check in on that in an hour or so and update the PR accordingly

[LivInTheLookingGlass]

You were right about divmod, by the way. Shaved off ~0.7us, and made it slightly more consistently fast.

[keis]

LGTM

[LivInTheLookingGlass]

Awesome, thanks