Refactor account processing implementation to be more efficient

[nullpointer0x00]

Description

closes: #552

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (see CONTRIBUTING.md)
• Linked to Github issue with discussion and accepted design OR link to spec that describes this work.
• Wrote unit and integration
• Added a relevant changelog entry to the Unreleased section in CHANGELOG.md
• Re-reviewed Files changed in the Github PR explorer
• Review Codecov Report in the comment section below once CI passes

[scirner22]

I see now - updateTokenCounts is suspended. I think you'll want to do the following because as it stands right now the subsequent line is ran before updateTokenCounts completes, and also whether it throws an exception or not.

Suggested change

	accountService.updateTokenCounts(record.processValue)
	runBlocking { accountService.updateTokenCounts(record.processValue) }

[scirner22]

I updated my suggested change above so that there's no blocking calls inside of the runBlocking, even this isn't idiomatic, but at least it's correct from a concurrency perspective and alleviates the need for a larger change surface area.

With this, the runBlocking on 449 can be removed.

[nullpointer0x00]

Yep, good catch. I was hoping not to use runBlocking at all, but all the grpc client methods use suspend. I decided I would look into why this pattern is used instead of change it.

[scirner22]

It's a great model, but requires up and down the stack to adhere to it. In this case, the jdbc driver is thread based calls so it requires constantly bridging blocking and nonblocking code.