Better logging when Rejecting join request from node

Who is this for and what problem do they have today?

On-prem users typically do re-use a node that used to be part of another Redpanda cluster. Without wiping out the data directory, the new Redpanda cluster rejects the request with

Rejecting join request from node {id: 38639, kafka_advertised_listeners: {{:{host: 10.0.0.0, port: 9092}}}, rpc_address: {host: 10.0.0.0, port: 33145}, rack: {nullopt}, properties: {cores 12, mem_available 0, disk_available 0}, membership_state: active}, logical version -1 < 3

For better usability, the logging should be more descriptive to make required action clear.

What are the success criteria?

When the logical version a new host has doesn't match, we should advise what to do:

• Ask if the node was part of another cluster
• If that's the case, ask to wipe out the data dir
• If that's not the case, any possible reasons?

Why is solving this problem impactful?

For better usability and supportability

Additional notes

JIRA Link: CORE-987

Start by tracing the node join request rejection path that emits the logical-version mismatch message. Review the existing message and the stated cases for reused nodes and data-directory cleanup. Done means the log clearly explains the likely cause and required action, while addressing what should be reported for other causes.