Remove backwards compatibility code to clean up codebase

[gacevicljubisa]

Remove backwards compatibility code to clean up codebase

Description

The codebase contains backwards compatibility code for Bee version 2.6.0 and potentially other older versions. As the network moves forward, this compatibility code is no longer needed and should be removed to improve code quality, performance, and maintainability.

Bee 2.6.0 Compatibility Code

The following Bee 2.6.0-specific compatibility code has been identified:

Affected files:

• pkg/p2p/libp2p/internal/handshake/handshake.go - WithBee260Compatibility option and field
• pkg/p2p/libp2p/libp2p.go - IsBee260() and bee260BackwardCompatibility() methods
• pkg/p2p/libp2p/peer.go - bee260Compatibility tracking map and related methods
• pkg/p2p/p2p.go - FilterBee260CompatibleUnderlays() function
• pkg/hive/hive.go - Bee260CompatibilityStreamer interface usage
• pkg/p2p/libp2p/version_test.go - Tests for 2.6.0 compatibility

Interfaces to remove:

• p2p.Bee260CompatibilityStreamer interface

Other Legacy Compatibility Code

Additional backwards compatibility code exists that may also be outdated:

Legacy address format compatibility:

• pkg/bzz/address.go - Underlay field in addressJSON for backward compatibility
• pkg/bzz/underlay.go - Serialization/deserialization logic for single vs. multiple underlay addresses
• pkg/bzz/underlay_test.go - TestLegacyCompatibility test

Other legacy code:

• pkg/crypto/crypto.go - LegacyKeccak256() function

Benefits

Removing this backwards compatibility code will:

• Simplify the codebase - Less conditional logic and special case handling
• Improve performance - Remove unnecessary version checks and filtering operations
• Reduce maintenance burden - Fewer edge cases to test and maintain
• Clean up interfaces - Remove compatibility-specific interfaces and types
• Improve code readability - Clearer intent without compatibility workarounds

Recommendation

Before removal, ensure that:

1. The network has sufficiently upgraded beyond version 2.6.0
2. A deprecation notice has been communicated to node operators
3. Any remaining nodes on old versions are identified and can be notified

Tasks

• Audit backwards compatibility for Bee 2.6.0 and confirm it can be safely removed
• Identify any other legacy compatibility code beyond what's listed above
• Remove Bee 2.6.0 compatibility option and related filtering logic
• Remove bee260Compatibility tracking from peer registry
• Remove Bee260CompatibilityStreamer interface
• Simplify underlay address serialization (remove legacy single-address format support if safe)
• Review and remove any other deprecated compatibility code
• Update tests to reflect the removal
• Document any breaking changes in release notes

[acud]

While we're at it, also old database migration code can be removed

[sbackend123]

I'm not convinced we should change LegacyKeccak256(). My impression is that the suggestion to modify or remove it was partly driven by the name Legacy, which sounds deprecated—but as I understand it, we still need this hashing for Ethereum-compatible behaviour.