chore: remove backwards compatibility with 2.6.0

[sbackend123]

Checklist

• I have read the coding guide.
• My change requires a documentation update, and I have done it.
• I have added tests to cover my changes.
• I have filled out the description and linked the related issues.

Description

Removed code for backwards compatibility with version 2.6.0

• WithBee260Compatibility
• bee260BackwardCompatibility() methods
• bee260Compatibility tracking map and related methods
• FilterBee260CompatibleUnderlays() function
• Bee260CompatibilityStreamer interface usage

Breaking change:
Single underlay address serialization is not supported anymore, wire encoding is now list-only.
The underlay prefix and deserialization of a single underlay address are kept for backward compatibility with the current network. Otherwise the handshake with bootnodes fails.

Open API Spec Version Changes (if applicable)

Motivation and Context (Optional)

Related Issue (Optional)

#5340

Screenshots (if appropriate):

AI Disclosure

• This PR contains code that has been generated by an LLM.
• I have reviewed the AI generated code thoroughly.
• I possess the technical expertise to responsibly review the code generated in this PR.

[acud]

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

[janos]

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

I agree, as there are still 2.6 nodes (not many, but still ~6%), it is early to release bee without compatibility.

This code is intended to be temporary. It is a good effort, but I would suggest to hold on merging, for some time.

[sbackend123]

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

I ran the previous bee version (v2.6.0) locally, let it sync to current block height on maiinet and build a real data directory. Then I started this build on the same data directory without clearing it. The node started successfully with no migration errors.

I also ran earlier versions trying to sync with mainnet, but get error connect new stream: incompatible stream: failed to negotiate protocol: protocols not supported.

[acud]

@sbackend123 I think that removing all migration code might be a bit too eager - can you make sure that the migration code covers the currently active bee node version still showing up in swarmscan?

I ran the previous bee version (v2.6.0) locally, let it sync to current block height on maiinet and build a real data directory. Then I started this build on the same data directory without clearing it. The node started successfully with no migration errors.

I also ran earlier versions trying to sync with mainnet, but get error connect new stream: incompatible stream: failed to negotiate protocol: protocols not supported.

I suppose it does not error the migrations because there's nothing to do in the migrations in the current build. I am not 100% sure about the reasoning behind the necessity of those migrations. But we should definitely leave in place the migration code to support the migration path from the node version still running on the network (2.6.0 definitely). The older ones we can mark as nops.