Fixing hashes core dependency and fuzz feature

[dr-orlovsky]

Caused by the latest bitcoin_hashes release

[TheBlueMatt]

We should drop this feature entirely now, its been replaced with an explicit --cfg=fuzzing

[sgeisler]

Is there any chance that people integrated this recusively into their fuzzing pipeline just as we did with bitcoin_hashes? If so this is a breaking change.

[TheBlueMatt]

I would be very surprised if that were the case, though, indeed, its possible. Ultimately its still just in fuzzing pipeline(s), so hopefully not anything that would break any release builds anywhere.

[dr-orlovsky]

So I assume we need to leave this as is for 0.26.1 and drop in 0.27?

[TheBlueMatt]

If we're not going to yank bitcoin_hashes (which I'm fine with either way) then we can call it a consistent policy. Probably the only thing that will break is rust-Lightning's fuzz crates, and I'm fine dealing with that :).

[TheBlueMatt]

Its a little bit confusing that we now have a fuzztarget feature which does nothing at all - you have to set cfg=fuzzing to get any behavior out of it. I think we should drop it.

[sgeisler]

Is there any chance that people integrated this recusively into their fuzzing pipeline just as we did with bitcoin_hashes? If so this is a breaking change.

[sgeisler]

From what I gather:

• the bitcoin_hashes version bump actually belongs into another (Error derive) PR (we should just yank 0.9.5 to make sure nobody uses it instead)
• removing the fuzz feature is breaking, but unless we also want to yank bitcoin_hashes 0.9.6 we better keep it in here to fix our fuzzing, consequences be damned
• relying on core directly is a valid fix, either to be done here or when bumping bitcoin_hashes to 0.10.0 which will include the removal

I wouldn't be too opposed to just yanking 0.9.5 and 0.9.6 of bitcoin_hashes, do a proper SemVer release 0.9.7 to be used in the error derive PR and also a 0.10.0 release down the road with the breaking changes to be included in rust-bitcoin 0.27.0.

[sgeisler]

Some more research showed that there probably isn't much of a problem as cargo avoids versions with missing features automatically.

[apoelstra]

I don't care about breaking fuzztarget users.

[apoelstra]

This is fine, even if we don't completely remove the fuzztarget feature.

[devrandom]

ACK, did something similar in #603