feat(v2): enable refetch on mount for storage responses

[justynoh]

Problem

Storage responses was not refetching until the admin refreshed the page. But once they refresh the page, they need to upload their secret key again, creating higher friction for admins to see their updated form responses.

Closes #4737

Solution

Remove custom refetch settings.

Also made some changes to the storage responses page for mobile responsiveness.

Breaking Changes

• No - this PR is backwards compatible

Screenshots

Screen.Recording.2022-09-08.at.5.07.28.PM.mov

[justynoh]

staleTime
Frankly, I picked 10s just as an order of estimation, but maybe setting staleTime isn't even the right approach at all - pls give me comments if so! 🙏 I took reference from the (soon-to-be-removed-removed-removed-REMOVED) "your submission may fail" query which doesn't even set the staleTime, so it always refetches haha. I didn't think refetching every time was necessary for this use but we can always just refetch always.

As for why 10s, we can look at some logs for reference. Not sure if this is super useful but also i figured i can just look at it to brush up on my cloudwatch syntax anyway ¯_(ツ)_/¯

Ran these queries at 11:07am on a Thursday over 3 hours, thus capturing logs from 8-11am on a weekday (our busiest traffic period).

The highest form got 980 submissions over 3h, which amounts to about 980/(3*60) = 5.44 submissions per minute, on average, so 10s is more than sufficient to update fast enough.

Looking from the admin perspective, we can find how many admins are interested in their storage submission metadata. In the same time period we can look at what's the first and last request for each form (duration is the time between the first and last request), and how many requests they made within that time period.

The maximum number of requests made was 293 in 3 hours, but that was within the span of about an hour. The remainder all made less than 100 requests. The duration was varying, though. This is very coarse-grained data, if we really want to know, we can look deeper into those who seemed to be "online" for a long time (e.g. for almost the whole 3h period) to determine what their usage patterns are.

[karrui]

should we also update the PR description?