HCP publishing endpoint for first time account creation

[shannonwells]

This PR implements one endpoint in the account-api to be called by the MCP server, which will be sending it 3 payloads. It creates an array of 3 encoded calls and enqueues it to a separate HCP queue. The account-worker has a new function for processing the HCP queue, which calls payWithCapacityBatchAll with each set of 3 calls.

I'm not fond of the name ('publishAll') I came up with, happy to hear suggestions

• Short proposal doc
• controller (in account-api)
• HCP enqueuing function in EnqueueService
• HCP BullMQ in account-worker, verified
• unit tests
• e2e tests
• generate swagger docs

[JoeCap08055]

nit: In order to keep mocks in a single place, and build up a complete chain mock over time, there's mockApiPromise in testlib/polkadot-api.mock.spec.ts. The pattern has been:

1. Add the mocked functions with an empty jest.fn() as the implementation
2. Override with a specific mock implementation in your test; this can be done in the top beforeAll(...) or in any specific test.

ie, in testlib/polkadot-api.mock.spec.ts, add to the tx property:

statefulStorage: {
  applyItemActionsWithSignatureV2: jest.fn(),
  upsertPageWithSignatureV2: jest.fn(),
}

Then in your test suite, just:

jest.spyOn(mockApiPromise.tx.statefulStorage, 'applyItemActionsWithSignatureV2').mockResolvedValue(mockSubmittableExtrinsic('0x01020304'));

[JoeCap08055]

nit: The pattern may not always have been followed, but we can try... my opinion, FWIW:
controllers should have little to no business logic. They just marshall the request/response; business logic is in a service component. This makes it easy to propagate endpoints to new controllers/API versions without having to duplicate business logic.

This also means that unit tests can focus on the service components, while controllers get tested primarily with a live HTTP request/response in an E2E test.

[shannonwells]

I had intended to make a service for this and backed out because it seemed like it was not enough code to be worth it. But I buy your separation of concerns argument.

[JoeCap08055]

nit: worth noting here that this is a "fake" delay simply to put this job back on the queue--under proper circumstances, since we've now detected we're out of Capacity, an event should have been emitted that paused the queue until the next epoch, which prevents us from just spinning on transactions while we're out of Capacity.

[shannonwells]

I was tired of this script continuing even when e.g. Docker daemon wasn't running.