Fix user_key and wid conflation bugs, rename arguments for clarity

[AnOctopus]

A chunk of the session state api had ambiguous argument names, from back when we were trying to make user keys and widget ids interchangeable rather than being clear and explicit. Renaming them revealed an issue with the checks in __setitem__, which is now fixed, and the prompting issue of not checking the right key for setting the frontend value is also fixed by adding a user_key argument.

I don't know how these two bugs were in there, because I thought we had tests for these cases, but maybe we do and those tests are just too narrow.

[AnOctopus]

Something I considered but didn't immediately decide to do is renaming the generic key argument to something that more clearly indicates that it could be one or the other, like lookup_key. Incidentally this would be a good candidate for an ADT, but that would be a larger refactor and keeping to a clear naming convention gives much of the benefit.

It is also worth considering totally excising the _get_widget_id method and replacing it with more explicit checks in the few places it is used, which might fit as part of this change.

[vdonato]

I haven't figured out exactly what's going on here yet, but this currently (surprisingly to me) introduces a regression to behavior similar to that described in #3534. The difference now is that it's every other click that gets reset unexpectedly

[AnOctopus]

I think the script in #3534 is inherently going to have that kind of issue with the transient widget model, because it sets one of the widget function's arguments to a changing value, which has the effect of making the code setting the "default" also reset the widget frequently, which will cause changes from the web app to be dropped (because they're for a no longer used widget).

import streamlit as st

st.title("Experimental: Play with Query Strings!")

app_state = st.experimental_get_query_params()
app_state = {
    k: v[0] if isinstance(v, list) else v for k, v in app_state.items()
}  # fetch the first item in each query string as we don't have multiple values for each query string key in this example

# [2] Radio
radio_list = ["Eat", "Sleep", "Both"]
default_radio = int(app_state["radio"]) if "radio" in app_state else 0
if "what_to_do" not in st.session_state:
    st.session_state.what_to_do = radio_list[default_radio]

radio = st.radio(
    "What are you doing at home during quarantine?",
    radio_list,
    key="what_to_do",
)

app_state["radio"] = radio_list.index(radio)
st.experimental_set_query_params(**app_state)

print("")

This is a modified version of the code using session state to only set the value if it doesn't exist.

I don't know why it would have been working before this PR, because it seems to me that it shouldn't have been.

[AnOctopus]

Actually I just tried the original script from 3534 and it has the same behavior on both develop and this branch

[vdonato]

It turns out the revival of #3534 currently exists on develop, so that isn't a blocker to get this PR in, and we can figure out what to do about #3534 regressing in a followup change

(edit: the behavior being revived here actually existed pre-session_state, so its revival is essentially a consequence of us choosing to revert widget identity semantics to what they were in the pre-state world)