fix(core): consistently generated session ids

[ejfitzgerald]

Proposed Changes

Summary of the Problem

Internally, the uAgents have a concept of an Internal and external context variants. The internal one was created and cached inside the agent object.

Due to the nature of the cached internal context, this would leads to some interesting outcomes specifically for the session id. In some cases (like a startup event) the session id can be None. Additionally, some session ids values are cached depending on the order of how handlers are called.

All of the above means that being able to reliable use the session id for chaining is difficult.

Consistent Generation of Session IDs

Semantically, this change ensures that the following rule is always applied:

The session id is always taken from the triggering envelope, when this is not possible a new session id is always generated

As a result of this, the code is updated so that the context is always built before it is used. This was always the case for the external context, but now is true for the internal context as well. This consistency eliminates some of the quirky cached behaviour that we had beforehand.

More importantly, however, this ensures that the session id can be used by the agent code to track responses from chained sessions.

Linked Issues

n/a

Types of changes

What type of change does this pull request make (put an x in the boxes that apply)?

• Bug fix (non-breaking change that fixes an issue).
• New feature added (non-breaking change that adds functionality).
• Breaking change (fix or feature that would cause existing functionality to stop working as expected).
• Documentation update.
• Something else (e.g., tests, scripts, example, deployment, infrastructure).

Checklist

Put an x in the boxes that apply:

• I have read the CONTRIBUTING guide
• Checks and tests pass locally

If applicable

• I have added tests that prove my fix is effective or that my feature works
• I have checked that code coverage does not decrease
• I have added/updated the documentation

Further comments

[if this is a relatively large or complex change, kick off a discussion by explaining why you chose the solution you did, what alternatives you considered, etc...]

[XaviPeiro]

Nothing necessary to change in here, quite clean and the change will allow us to apply specific logic on every internal use-case.

A general advise is use and enforce name parameters, it avoids errors when refactoring and increases intelligibility quite much.

[ejfitzgerald]

@Archento I have modified the code so that it is not coupled with the Agent interface. When you are back on Monday can we aim to review and land this please 🙏

[jrriehl]

LGTM