Major update changing how we identify amplitude users

[victor-cortez]

• Now we are able to add cookies to the browser using resources/cookiegen.html, which has a setCookie() javascript function and a handler function that will execute commands given as get arguments. Currently we have the cookie arguments and the argument to load the user with geolocation and ip data.

• Using those cookies amplitude will now take the geolocation cookie and use that information to feed amplitude. With that the geolocation (and possibly future user data features) now depends on information coming from the client side, and not the server side. This is still subject to adblockers and we are not trying to go over it. As of now we are only registering data from the user coming from http headers (although the IP needs to be registered through a third-party to go over streamlit restrictions)

• Also using those cookies we store a unique user id in each user's browser. If the cookie is already present we use it as the id for amplitude and if not present we create a new one. This way we can track users way better than before when we just relied on the server-side ip.

• Solved the problem of pointless amplitude logs due to cascade rerunning. Now we have an amplitude logging manager that receives the call for an event but decides if the event is worth logging or not by using our session makeshift db. This is to avoid us logging multiple times the same event when the page reloads.

• Also added minor changes to Saúdem em ordem's description

• Also fixed some of streamlit's timing problems that were causing bugs in our mobile version by adding some small wait and page reload triggers.

[fernandascovino]

Adicionar cookies no Streamlit

[fernandascovino]

I added a for-now-fix on the capacity card display - it wasn't changing with data cases change because it gets the value from user_input["population_params"]["I"]"...

let's end user_input and just work with session_state? I think it's a better way to solve ir for good