feat(tenants): initial tenants module

[TimoGlastra]

Initial version of the tenants module. This is not fully finished yet and ready for prime time, but it contains most of the things needed for multi-tenancy. It doesn't introduce any breaking changes (those were addressed in the PRs this PR depends on).

Dependant on:

• refactor!: add agent context #920
• feat: add agent context provider #921
• feat: add base agent class  #922

Until the modularization is fully here the API for registering module is not really nice, but I see that as a separate task that we can address after multi-tenancy has been merged. This is how you use it:

import { DependencyManager, Agent } from '@aries-framework/core'
import { TenantsApi, TenantsModule } from '@aries-framework/module-tenants'
import { agentDependencies } from '@aries-framework/node'

// create dependency manager and register module
const dependencyManager = new DependencyManager()
dependencyManager.registerModules(TenantsModule)

// create agent, and resolve tenants api
const agent = new Agent({ /* config */, agentDependencies , dependencyManager)
const tenantsApi = agent.dependencyManager.resolve(TenantsApi)

const tenantRecord = await tenantsApi.createTenant({
  config: {
   label: 'Tenant 1',
  },
})

const tenantAgent = await tenantsApi.getTenantAgent({
  tenantId: tenantRecord.id,
})

// Create oob invitation in scope of tenant
const outOfBandRecord = await tenantAgent.oob.createInvitation()

I would like to already merge so we can keep PRs reasonable (this is already getting quite large).

Basically the only thing that's left to do is correctly managing the tenant lifecycle and managing tenant sessions (see https://hackmd.io/vGLVlxLvQR6jsEEjzNcL8g?view#Tenant-Lifecycle). Currently, wallets are being opened when needed and will not be closed afterwards. That means over time the number of open wallets keeps increasing. Correctly opening wallets and avoiding race conditions if two sessions would like to open the same wallet is handled (using async-mutex library). This does need some improvements in not waiting indefinitely.

Concrete what's still todo:

• Agent lifecycle. Currently you call getTenantAgent with no proper way to dispose of the agent (session count won't be reduced)
• Check we're not using context after a process is complete (e.g. by setting an event listener). This should always start a new session instead of using the session from the upper scope

I'm quite happy with how it turned out and how multi-tenancy is an optional addon without having the code in the core package.

[codecov-commenter]

Codecov Report

Merging #932 (a1613b1) into 0.3.0-pre (96c5ef8) will increase coverage by 0.21%.
The diff coverage is 95.95%.

@@              Coverage Diff              @@
##           0.3.0-pre     #932      +/-   ##
=============================================
+ Coverage      86.70%   86.91%   +0.21%     
=============================================
  Files            518      531      +13     
  Lines          12603    12854     +251     
  Branches        2137     2181      +44     
=============================================
+ Hits           10927    11172     +245     
- Misses          1581     1587       +6     
  Partials          95       95              

Impacted Files	Coverage Δ
packages/core/src/agent/Events.ts	100.00% <ø> (ø)
packages/core/src/agent/context/AgentContext.ts	83.33% <0.00%> (-16.67%)	⬇️
...ges/core/src/agent/models/InboundMessageContext.ts	77.77% <0.00%> (-22.23%)	⬇️
.../core/src/modules/connections/ConnectionsModule.ts	67.24% <ø> (ø)
packages/core/src/wallet/IndyWallet.ts	63.28% <20.00%> (-0.87%)	⬇️
...le-tenants/src/context/TenantSessionCoordinator.ts	97.22% <97.22%> (ø)
packages/core/src/agent/Agent.ts	97.56% <100.00%> (+0.01%)	⬆️
packages/core/src/agent/AgentConfig.ts	95.00% <100.00%> (+4.83%)	⬆️
packages/core/src/agent/BaseAgent.ts	95.29% <100.00%> (+2.03%)	⬆️
packages/core/src/agent/EventEmitter.ts	100.00% <100.00%> (ø)
... and 17 more

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 96c5ef8...a1613b1. Read the comment docs.

[karimStekelenburg]

Nice work! Looks good to me. I left two comments, but those are minor things.

Additionally, maybe it's nice to add methods for creating and getting multiple tenants. E.g. createTenants([{...}, {...}, {...}, {...}]). Maybe that is too difficult regarding sessions management tho. Idk, just a thought.

[TimoGlastra]

Additionally, maybe it's nice to add methods for creating and getting multiple tenants. E.g. createTenants([{...}, {...}, {...}, {...}]). Maybe that is too difficult regarding sessions management tho. Idk, just a thought.

We could. Do you think it will be an often used use case to create a lot of tenants at the same time? I'd like to keep the API minimal, so if you have a good use case for it, I'd be happy to add it.

[karimStekelenburg]

Additionally, maybe it's nice to add methods for creating and getting multiple tenants. E.g. createTenants([{...}, {...}, {...}, {...}]). Maybe that is too difficult regarding sessions management tho. Idk, just a thought.

We could. Do you think it will be an often used use case to create a lot of tenants at the same time? I'd like to keep the API minimal, so if you have a good use case for it, I'd be happy to add it.

So I can't think of a good use case for creating multiple tenants atm, but I can imagine wanting to execute some kind of action in batch for multiple tenants at the same time (e.g. creating a connection invite). In this case a getTenants method could be useful.

[TimoGlastra]

So I can't think of a good use case for creating multiple tenants atm, but I can imagine wanting to execute some kind of action in batch for multiple tenants at the same time (e.g. creating a connection invite). In this case a getTenants method could be useful.

Ok, I've made some changes to these method in a next PR. Let me look at it in that branch and see If I can come up with nice API

[TimoGlastra]

Merging as only failing test is the one from #923