Use v-once and/or v-memo with submissions table

[matthew-white]

v-once and v-memo are mentioned as options for improving performance on this page. The documentation for v-memo says:

v-memo is provided solely for micro optimizations in performance-critical scenarios and should be rarely needed. The most common case where this may prove helpful is when rendering large v-for lists (where length > 1000)

The submissions table seems like a good example of that case.

That said, I've already reduced the reactivity of the submission requestData. That means that the submission row components already have very few reactive dependencies. If there is limited reactivity already, would v-once and v-memo have any additional benefit? My guess is yes, because even if the submission requestData is minimally reactive, the component props are still reactive: the submission row components don't know that they're used within a context that guarantees that their props are immutable.

[matthew-white]

We're planning to add pagination to the submissions table, which should help a lot with performance. I'm going to go ahead and close this issue. We can always reopen it if there are issues with performance after pagination is introduced.

[matthew-white]

the submission row components don't know that they're used within a context that guarantees that their props are immutable.

As of #1043, it's no longer the case that the props of SubmissionMetadataRow are immutable: the awaitingResponse prop will change after the delete button is clicked.