feat: inject profile and session

[dbluhm]

This is yet another attempt at #2705 which was reverted in #2789 because of issues reported in #2777. This time, I have explicitly tested using the integration tests in the Multitenant provider plugin to ensure the same issue does not arise.

The same benefits mentioned in #2705 of course apply here. This makes it easier to provide pluggable components that depend on a Profile without the interface of those components accepting a profile in every method.

The primary difference between this PR and #2705 is that this ensures a unique scope based on wallet id of multi-tenant subwallets.

I have also tacked on injecting the session. This enables binding dependencies that require a session from plugins and other components. For instance, the DIDComm v2 work in #2959 could use this to bind a provider for the SecretsAdapter needed to provide access to Askar to the pack and unpack methods.

[dbluhm]

This should help with unit testing, too?

@jamshale I hadn't thought about that but this could be used to inject test/mock dependencies in unit tests. We had strategies to do this already though so I'm not sure it changes too much. If we took advantage of this in more places, mocking dependencies would be simpler but that would require transitioning more places to using the injected profile.

[dbluhm]

I've still got issues with entering a scope that isn't unique in the integration tests... I will take a deeper look. I'm beginning to question the value of the named scopes. ContextVars, for instance, don't name the contexts and require them to be globally unique. I'll look into that angle.

[dbluhm]

I removed named scopes entirely. They served no significant purpose in practice and they were causing all sorts of trouble.

[dbluhm]

@jamshale Yeah, the tests implied that there was some perceived use to the named scopes at some point in the past but it looks like in practice they were just never really used.

You could "recall" a particular scope by name and retrieve values out of it. But this would only ever be possible from a parent scope and it's just not common practice to, for example, obtain the bound values of a session from the profile scope that spawned it. That would probably be a bad idea, in fact lol.

In practice, the lifetimes of the InjectionContexts and references to the contexts are, I think, appropriately narrow and naturally fall out of (lexical) scope at the right times. So we don't need to access the scopes by name since we're using the references to them as bound to a profile or session, etc.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
No data about Coverage
No data about Duplication

See analysis details on SonarCloud