Use the query_obj as the basis for the cache key

[mistercrunch]

When we recently moved from hashing form_data to define the cache_key
towards using the rendered query instead,
it made is such that non deterministic (time-relative) form
control values like relative times specified in "from" and "until" time
bound resulted in making those miss cache 100% of the time.

Here we move away from using the rendered query and using the query_obj
instead. For this to work, we need to remove ['from_dttm', 'to_dttm'] and add some keys (['since', 'until', 'datasource']) from form_data

[john-bodley]

@mistercrunch doesn't the query object include the form_data and thus wouldn't this issue still persist? #3840

[mistercrunch]

@john-bodley oh man. Good catch. I had forgotten that the query_obj contains the form_data. It's used for templating use case the user is using a tempalted SQL query (a Superset view), coming from SQL Lab.

Now I still think this is the right high level approach, but that we need to mitigate the templating use case somehow. Maybe have users opt-in on passing the form_data (?). Perhaps a new Slice boolean "allow form_data templating". Templating brings potentially other problems around things being non-deterministic... Let me do a bit more thinking here.

[mistercrunch]

What about I deprecate using form_data in templates? Can you run a query as to whether and how it's used at Airbnb?

Here's the query to figure that out:

SELECT * FROM tables WHERE sql like '%{{%form_data%}}%'

[john-bodley]

@mistercrunch I slight tweak to the query, but

SELECT * FROM tables WHERE 'sql' LIKE '%%form_data%%'

returned zero rows (ran in SQL Lab).

[hughhhh]

👍

[john-bodley]

LGTM