[Feature]: Show a warning when CKAN detects CKAN files for an identifier selected or being downloaded as a dependency that have a newer spec than the CKAN version about ckan

[HebaruSan]

When this happens, UnsupportedKraken is thrown by CkanModule.FromJson and handled here for freshly downloaded metadata:

CKAN/Core/Repositories/RepositoryData.cs

Lines 341 to 352 in eaefca5

	if (exception is UnsupportedKraken || exception is BadMetadataKraken)
	{
	// Either of these can be caused by data meant for future
	// clients, so they're not really warnings, they're just
	// informational.
	log.InfoFormat("Skipping {0}: {1}", filename, exception.Message);
	// I'd *love a way to "return" from the catch block.
	handled = true;
	break;
	}

There's also a JSON converter for when we load cached data from disk after saving it with a newer client:

• CKAN/Core/Repositories/AvailableModule.cs

  Lines 67 to 70 in eaefca5

  	[JsonProperty]
  	[JsonConverter(typeof(JsonLeakySortedDictionaryConverter<ModuleVersion, CkanModule>))]
  	internal SortedDictionary<ModuleVersion, CkanModule> module_version =
  	new SortedDictionary<ModuleVersion, CkanModule>();

• CKAN/Core/Converters/JsonLeakySortedDictionaryConverter.cs

  Lines 17 to 36 in eaefca5

  	public class JsonLeakySortedDictionaryConverter<K, V> : JsonConverter
  	{
  	public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
  	{
  	var dict = new SortedDictionary<K, V>();
  	foreach (var kvp in JObject.Load(reader))
  	{
  	try
  	{
  	dict.Add(
  	(K)Activator.CreateInstance(typeof(K), kvp.Key),
  	kvp.Value.ToObject<V>());
  	}
  	catch (Exception exc)
  	{
  	log.Warn($"Failed to deserialize {kvp.Key}: {kvp.Value}", exc);
  	}
  	}
  	return dict;
  	}

In both cases unsupported modules are noted in the log and then skipped because the older client can't handle them. To alert the user, we would have to propagate a message out to GUI in some way, and it's not obvious to me how we could do that.

[HebaruSan]

Thinking about the code level interface for this, it might make sense to extend the enum that the repo update process returns:

CKAN/Core/Repositories/RepositoryDataManager.cs

Lines 112 to 121 in eaefca5

	/// <summary>
	/// Values to describe the result of an attempted repository update.
	/// Failure is actually handled by throwing exceptions, so I'm not sure we need that.
	/// </summary>
	public enum UpdateResult
	{
	Failed,
	Updated,
	NoChanges,
	}

RepositoryDataMaanger could return a new OutdatedClient option if any unsupported modules are found, and GUI could use that as a signal to prompt the user to update their client, maybe with a yes/no dialog.