Fix for several Shopping List bugs

[michael-genson]

What type of PR is this?

(REQUIRED)

• bug

What this PR does / why we need it:

(REQUIRED)

This fixes several issues with the shopping list feature. Once #1847 is merged I think I'll take another look at the backend shopping list service because I think there are some additional improvements to be had.

The main issues this PR addresses are around the auto-refresh we implemented fairly recently - it broke... a lot more than I thought it did, as you'll see below. This PR more-or-less restores the shopping list back to how it used to behave for the user, but keeps the auto-refresh intact which required some changes. It also fixes a backend bug where checked items were being merged with unchecked items.

Below are two of the bigger frontend changes:

Editing Items

The current state of the shopping list makes it virtually impossible to modify individual items on multiple fronts, since a refresh overwrites any changes a user is in the middle of making. Here is an example from the current build:

You can see my changes are just being replaced by the original value. My solution in this PR is to basically copy the item in the component which is edited, and then once the user saves the item the copied item emits up to the main component to replace it.
Not pictured: I'm monitoring the network to make sure we are, in fact, still polling.

Performing a ton of actions at once

We implemented a loading value to make sure a refresh doesn't occur when we're still doing some work (e.g. updating a recipe reference, which takes a while). However, if you do a ton of things at once, whatever finishes first sets the loading value to False. That leads to behavior like this where items pop in and out (note: in the gif the issue takes 4-5 seconds to appear):

So I replaced the loading bool with a loadingCounter int. Every list action that pauses loading increments the counter, then decrements it. Refreshes only occur when the loading counter is zero (thus everything is done loading).
Not pictured: network requests for the updated list stop until all the operations are done (the gif continues until all network requests finished and the first refresh occurs)

Which issue(s) this PR fixes:

(REQUIRED)

N/A

Testing

(fill-in or delete this section)

I testing this much more robustly: adding a ton of recipes at once, incrementing them, decrementing them, editing one item, editing several items, etc. Everything seems nice and responsive.

One drawback of this approach is that when you edit an item, it waits for the backend call to show the updated item to the user (you can see this in the second gif where the update is successful, but it takes a sec). I think this is okay, since it gives the user visual feedback that the change did indeed occur and nothing went wrong, but we lose that instant responsiveness. We could probably change this so the update is shown to the user before the backend call, but I'm unsure if we want to. Maybe I'm over thinking it.

Release Notes

(REQUIRED)

increased shopping list responsiveness
fixed an issue where adding a recipe to a shopping list that has checked items will sometimes uncheck them

[michael-genson]

@hay-kot FYI this should be ready :)