Add Get Feed Property block

[tyeth]

This adds a Get Feed Property block, to facilitate comparing last updated etc, and easily retrieving feed keys / status.

Then the idea would be to replace this action's Liquid template usage with time + feed_property blocks:

[tyeth]

@brentru @tylerdcooper @jwcooper any other feed related properties you want?
I wonder if we could possibly pull recent aggregate data, like the last 5min/15min/1hr value (not sure the aggregation windows).

As I exposed the last_value/previous value option, it felt sensible to include the current value in the list. At that point maybe the original Get Feed block could be replaced/migrated to this Get Feed Property block with the property pointed at Current Value.

[lorennorman]

This is needed! I do think this should replace the existing feed block completely, when its ready.

Re: current/last value, I'm pretty sure there is no difference. We only store 1 value in the DB, can't query any further back. The only place where we have 2 values is in the feed triggers (I had to do an epic code/schema change to get this working in the hot path!) We could expose the "active trigger" to the action itself and have the 2 values available on that block somehow.

Other property thoughts:

• feed key: do we want to expose just the feed's key, vs the group.feed compound key?
  • also, the compound key will be different depending which version of a feed they select (feeds will appear in the list once for each group they are a part of. i never know how to think about this definitively)
• *_at: gets into time stuff, need to make copacetic with time things, handle timezones, etc
• unit type/symbol: i don't know what these actually are, let's make sure we want to expose
• status: should probably show that it is either "online" or "offline"
• visibility: same, "public" or "private"

(Haven't looked at code yet.)

[lorennorman]

this seems reasonable! wow that's a lot of tests, interesting.

it's missing something, has to be added a regenerator list somewhere that maps between the blockly block type and the io bytecode key... or something like this, just global search for another block type and you'll find it.

i wouldn't approve fully until:

• we talk about it more
• we get the Ruby side built out
• we decide and implement a migration to replace the old feed block
  • this will include more code here, not just ruby

[lorennorman]

can add a third element to each option, will be used in the docs