Re-factor/re-name blockdata

[tcharding]

This is a re-do of the first three patches in #525. The git log for each commit is a bit light on why we should be doing this (because I'm more or less blindly following #525 after about 30 seconds of "hmm seems reasonable").

[tcharding]

Woops fuzzing, will re-spin tomorrow if I get a concept ACK.

[Kixunil]

Why renaming? I think blockdata was fine.

[dpc]

Why renaming? I think blockdata was fine.

I was not participating in any discussions about it, but to me it always seemed superfluous, and block data seems and its decoding and encoding seems like a centerpiece of the whole crate. And generally there module namespace seems to have more depth then necessary.

[apoelstra]

The goal here is to move this stuff into its own crate, which would contain this data as well as compact blocks (bip 158), maybe addresses and hashes, etc., which is not all "block data".

[Kixunil]

In my experience Transaction and everything it contains is used very often, almost always. OTOH use of things like network or bip* is very project-dependent.

[apoelstra]

@Kixunil right, so it would be nice if Transaction etc were in its own crate without any of those other things

[tcharding]

Fixed paths in fuzz code.

[tcharding]

If primitives is to become a crate would Amount go into it or do we want it separate in bitcoin-units still?

[apoelstra]

IMHO, if Amount would force a dependency of primitives on -units, then it should be in primitives and not units.

But if the dependency would exist anyway, which I suspect would be the case, then Amounts more properly belongs in -units.

caveat: I am just spitballing here and will probably forget I said this the next time we have a problem that suggests the opposite thing would be wise :)

[Kixunil]

Is primitives supposed to mean blockdata? If yes, it's not a good name because I already don't know what goes into them.

if the dependency would exist anyway, which I suspect would be the case

Indeed, methods like target(), work(), witness_size() will return units. We could make them optional but that seems too much. This touches the question of should TxAmount be a separate type? If yes, then I'd be more open to having units optional but still not convinced.

[apoelstra]

All the bitcoin primitives go into bitcoin-primitives. To a first approximation, everything defined in src/primitives/*.h in Bitcoin Core. blockdata is weird and rust-bitcoin-specific and as I've mentioned, I don't think it's properly descriptive.

I think conceptually bitcoin-primitives should depend on bitcoin-units. I could also get behind -primitives and -units being merged.

[Kixunil]

Defining things by in which file Core has them doesn't sound great.

[tcharding]

I've rebased but I don't know whats the decision on this one, perhaps we should leave this until we discussed our next moves. Converting to draft.

[Kixunil]

I'm thinking I will try to pull Wight and FeeRate into units once the #2408 is merged, then move around decoder impls from #2184 and try to pull primitives out.

[tcharding]

Sweet, I've had a couple of goes and keep getting tied in knots.

[Kixunil]

keep getting tied in knots.

Oh, hell, this is much worse than I thought...

[tcharding]

Consumed by #2756