DHV: fix unmet claims handling for terminal allocations

[tgross]

When we feasibility check dynamic host volume claims for "sticky" volumes, we need to ensure that new allocations are preferentially places on nodes that the job has previously been on. In #27470 we fixed a bug where we were incorrectly handling proposed allocations for the eval, but this fix missed handling of terminal allocations. If an allocation is terminal (server or client), we don't want to count it among the allocations that match a claim, so that we free the claim up for allocations that are replacing it.

Add a check for terminal allocations in the feasibility check. Extract this check out to a function so that it can be tested, and add tests.

While debugging this issue, I discovered that the claims upsert read existing claims out of a read transaction in the middle of the write transaction. This makes it possible for the read to see a stale version that doesn't include any changes from the current write (because go-memdb does not permit dirty reads). Correct this, and extract the claims upsert logic to a method we can test.

Improve logging and assertions for the E2E test to make this bug easier to understand as well.

Ref: #27470
Ref: https://hashicorp.atlassian.net/browse/NMD-1267

Contributor Checklist

• Changelog Entry If this PR changes user-facing behavior, please generate and add a
  changelog entry using the make cl command.
• Testing Please add tests to cover any new functionality or to demonstrate bug fixes and
  ensure regressions will be caught.
• Documentation n/a

Reviewer Checklist

• Backport Labels Please add the correct backport labels as described by the internal
  backporting document.
• Commit Type Ensure the correct merge method is selected which should be "squash and merge"
  in the majority of situations. The main exceptions are long-lived feature branches or merges where
  history should be preserved.
• Enterprise PRs If this is an enterprise only PR, please add any required changelog entry
  within the public repository.

• If a change needs to be reverted, we will roll out an update to the code within 7 days.

Changes to Security Controls

Are there any changes to security controls (access controls, encryption, logging) in this pull request? If so, explain.

[pkazmierczak]

LGTM!