Unexpected IsHardforkEnabled behaviour

[AnnaShaleva]

Describe the bug
Take a look at the IsHardforkEnabled function:

neo/src/Neo/SmartContract/ApplicationEngine.cs

Lines 613 to 620 in 9464107

	public bool IsHardforkEnabled(Hardfork hardfork)
	{
	if (PersistingBlock is null)
	return true;
	if (!ProtocolSettings.Hardforks.TryGetValue(hardfork, out uint height))
	return true;
	return PersistingBlock.Index >= height;
	}

This function assumes that if some hardfork is not specified in the configuration, then it's considered to be enabled starting from the genesis. Imagine that a NeoC# node operator has an old v3.5.0 config with HF_Aspidochelone hardfork specified. After that, imagine that the node operator upgrades his node up to the new v3.6.0 release preserving the old config. The operator expects things to work the same way, but suddenly he gets HF_Basilisk enabled which breaks the node. Ref. nspcc-dev/neo-go#3056 (comment), #2881 and #2884.

Expected behavior
If there are any hardforks explicitly specified in the node config, then the rest of them (the missing ones) are expected to be disabled, so that the node won't change its behaviour after the binaries upgrade. If there's no hardforks explicitly specified in the user's config file, then the default behaviour is to enable all hardforks from the genesis.

Platform:

• Version: Neo pre-3.6.0