update bundling workflow and add task locking for bundles

[CollinBeczak]

Simplified rebase of #2500
partially resolves: #2540
potentially resolves: #1495

Issue

Bundles are not being reset or deleted when a user remains inactive for an extended period, allowing them to bypass the bundle reset conditions. This leads to various issues, such as finalized conditions in the completion step not being properly set.

Solution

Instead of updating bundles in the database every time they are created or edited, they will now only be modified when a user completes a task. The task lock status will prevent other users from bundling tasks that have already been bundled by another user.

New Functionality

• Add individual tasks to a bundle
• Delete bundles when creating a new bundle
• Improved bundle editing flexibility:
  • Users can now delete existing bundles and which allows them to also utilize the lasso tool
  • If a bundle exists when opening a task, users can reset it to its initial state
  • The "Review Nearby Tasks" widget has been updated and will likely be available in both the completion and review flow

[jake-low]

LGTM

[jake-low]

I see there was a bug in this logic that you fixed already. FWIW I like to write complex conditionals like this in pieces, like this, which IMO helps with readability.

const isAtMaxZoom = (this.props.criteria?.zoom ?? 0) >= MAX_ZOOM;
const tooManyTasksToShowUnclustered = this.state.taskCount > UNCLUSTER_THRESHOLD;
const showAsClusters = !isAtMaxZoom && (wantToShowAsClusters || tooManyTasksToShowUnclustered) && !this.props.createTaskBundle;

Another trick is to move the logic into a helper function where you can use the early return pattern.

function showAsClusters() {
  if ((this.props.criteria?.zoom ?? 0) >= MAX_ZOOM) {
    return false; // don't cluster at max zoom
  }
  if (this.props.createTaskBundle) {
    return false; // don't cluster when the user is creating a task bundle
  }
  if (this.state.taskCount > UNCLUSTER_THRESHOLD) {
    return true; // always cluster if there are tons of tasks visible
  }
  // otherwise respect the user's preference for whether or not to cluster
  return wantsToShowAsClusters;
}

The latter is more verbose, but that actually has a hidden benefit: combinations of conditions that aren't tested will show up in code coverage results (whereas a single big conditional expression will always be hit, so you may not realize that your tests don't exercise every possible combination).