Update bitarray dependency

[coreycerovsek]

I noticed that the bitarray dependency could be updated with only minor changes as per Bitarray 3 transition. Note that with an unchanged lower bound this makes the API exported via Bits.tobitarray() implicitly dependent on the user's installed version of bitarray. With the changes, tests pass with either of bitarray 2.9.3 or 3.0.0 installed, so bitstring itself appears agnostic. The lower bound could be raised to 3.0.0 with the effect of fixing the exported bitarray API, but I don't know whether that's an issue for anyone downstream. (For me, bitstring is only a dependency of angr via PyVEX, and I don't immediately see any consequences from updating bitarray.) Thanks for the package!

[scott-griffiths]

Thanks, I hadn't noticed that version 3 of bitarray had dropped. The change looks good to me (the CI is broken for another reason!)

If the required version of bitarray still allows 2.9.x then it will be a performance regression to switch from itersearch to search, so I think I will have to raise it to 3.0 (or code it differently for each version). I'll take a proper look later.

[coreycerovsek]

Thanks, I hadn't noticed that version 3 of bitarray had dropped. The change looks good to me (the CI is broken for another reason!)

If the required version of bitarray still allows 2.9.x then it will be a performance regression to switch from itersearch to search, so I think I will have to raise it to 3.0 (or code it differently for each version). I'll take a proper look later.

bitstring itself is unaffected (as search is already provided by bitarray 2.9.x, ergo bitstring's tests passing with both versions of bitarray) but I wasn't sure about the semantics of the guarantee made to users of bitstring in turn — the Bits.tobitarray docs only promise to return a bitarray object from the bitarray package, but the current version of bitstring more specifically returns a bitarray 2 object, of course. With either lower bound a bitstring user might experience a regression with the new upper bound, so I wasn't sure which behaviour would be preferable in the immediate. Very happy to push a commit with the 3.0.0 lower bound instead, if it's helpful!

[scott-griffiths]

No need to change anything more - I'll fix the CI, merge this in and then make any further changes I need after.