Not all flow.json syntaxes are supported for account keys

[jribbink]

Instructions

Issue To Be Solved

Currently, the Flow CLI supports 4 different ways for specifying account keys in the flow.json.

Unfortunately, the VSCode extension only supports one of these - the simple format post-flow-cli-v0.22. Because vscode-cadence relies on a signature match in order to verify emulator liveliness, this presents a problem to developers attempting to use any of the 3 other formats.

(Optional): Suggest A Solution

I think parsing flow.json is inherently a bit dangerous regarding compatibility and should be avoided as much as possible. While we could trivially support the "key" and "keys" variations of accounts in flow.json, this doesn't account for advanced account keys at all. We could obviously support all signing algorithms, etc. required for advanced account keys as of now, but implementing this is a lot of work & has a high risk of becoming outdated/incompatible yet again.

Considering that we only use this functionality to test emulator liveliness & everything else done regarding account keys is handled by the language server/golang side I think it would make more sense to do the following:

1. Wait for emulator to start using port/hostname like we do now
2. Send a dummy transaction using language server command in order to verify that we have the correct emulator.

This would produce exactly the same result as we have right now and leave the flow.json logic to the edge/Golang side.

(Optional): Context

Took me far too long to use the extension in kitty-items. After discovering why, I realized that we potentially don't support a number of existing flow.json files and this should probably be looked at (especially considering kitty-items is more or less the quintessential dapp example).

[sideninja]

@jribbink This is a good point about supporting schema changes. I would say tho that kitty-items is no longer a good example to test anything against as it hasn't been updated in too long. The "keys" has been deprecated since. But I agree we could change the check to something different, like sending an empty transaction.