Deprecation check for File Discovery plugin

[gwbrown]

Adds a deprecation warning that the file discovery plugin is no longer
needed and that the path it uses has changed.

Relates to #36024 and #33257

[elasticmachine]

Pinging @elastic/es-core-features

[DaveCTurner]

I think this needs to be two independent checks:

1. the discovery-file plugin is not in use, and
2. the path to the unicast hosts file is correct

This is because in versions ≥ 6.5.0 you can be using the old path without using the plugin, and in that situation AIUI this warning won't fire.

[gwbrown]

@DaveCTurner I agree that would be better, however it looks like a fair bit of plumbing work to get that information through the NodeInfo API (or modify the deprecation check framework to support getting information another way). Am I wrong there?

This is an interesting one, as there doesn't look like a clean way to expose this easily.

[elasticmachine]

Pinging @elastic/es-distributed

[DaveCTurner]

I see. Yes, you're right, apart from logging a deprecation warning we don't record that the discovery file isn't in the new place.

I think if the file is not in the right place on 7.0+ nodes during an upgrade then the upgraded nodes will struggle to join the cluster, which seems ok. It depends a bit on whether they're using file-based discovery exclusively or some combination of other discovery mechanisms too, but if it's exclusively file-based discovery then no file means no discovery. Am I right that the migration assistant is intended to be a best-effort thing? If so then this is going to be ok.

[gwbrown]

@DaveCTurner I believe that yes, the migration assistant/deprecation info API is intended to be best-effort. Users will still need to check the deprecation logs for any request/response format changes they'll need to make anyway.

I've opened #36343 to track the larger issue, but it's unlikely to be addressed before the release of 7.0, so I think it might be best to move forward with this as-is.

[DaveCTurner]

Ok, this LGTM then, thanks for the explanations @gwbrown.