ci: remove inputs invalidated by #22050 removing tor v2 support #63

See https://github.com/bitcoin/bitcoin/pull/22050/commits/eba9a94b9f56be2fda623e77f19b960425ea1eb5

previous name:

netaddr_deserialize
service_deserialize
sub_net_deserialize

renamed to:

net_address_deserialize
net_service_deserialize
subnet_deserialize

Hm, I'm not sure this is needed / don't think it is. Feel free to close if that is the case.

Would there be a downside of renaming the fuzz targets back to the original name?

I think you might have been motivated by #62 to rename the target. That one changed the whole format, so fuzz inputs might only work "by accident" for the new target.

However, I think the target shouldn't be renamed when the format largely stays the same (as it is here) and only some inputs are "invalidated" (probably meaning "do not increase coverage meaningfully"). In fact we see fuzz input "invalidation" almost daily. Pretty much every code change that touches code that is covered by existing inputs may "invalidate" some inputs. Here, ipv4 (and ipv6 etc...) inputs are not invalidated AFAICT.

Also, a risk with deleting inputs is that "actual seeds" (patterns or whole inputs that have been injected manually without running a fuzz engine) will get deleted as well. Modern fuzz engines might pick up inputs that are considered "invalid" and evolve them into useful ones.

I don't think anyone did add any manual seeds for #62 or this fuzz targets in this pull, so I think deleting them is fine. Though, we should understand that this is not a general best practise and comes with risks and downsides.

<!-- Interestingly, fuzz inputs are also surprisingly resistant against minor format changes. I presume that settings like `-use_value_profile=1` blow up the input corpus and thus evolve several inputs that exercise the same lines of code. Then

I think what #62 should have done is move the inputs, not remove them. Deletion will already happen automatically whenever delete_nonreduced_fuzz_inputs is run.

Thanks for the helpful replies!

Would there be a downside of renaming the fuzz targets back to the original name?

Renaming the targets back to the original names seems to work for me locally. Let's see what the CI thinks. I had a post-merge Span fixup and an RPC fixup that can be done at the same time.

Yay, CI passed so closing here.