Simplify HTTP Plugin architecture

[heyitsaamir]

Separate activity sending from HTTP transport layer

The previous architecture tightly coupled HTTP transport concerns with activity sending logic:

Previous Architecture:

HttpPlugin (transport) → implements ISender (sending)
                      → has send() method (creates new Client per call)
                      → has createStream() method
                      → knows about Activity protocol details

ActivityContext → depends on ISender plugin
               → cannot work without transport plugin
               → conflates transport and sending concerns

There are a few issues with this:

• HttpPlugin created NEW Client instances on every send() call. So there's really no benefit of this logic being in the "httpclient" plugin.
• Transport plugins (HttpPlugin) were forced to implement send/createStream. This makes it more cumbersome to build your own HttpPlugin with your own servier.
• Users couldn't "bring their own server" without implementing ISender
• ActivityContext was tightly coupled to plugin architecture. ("Sender" was coupled with an activity, without any necessary benefits.)

New Architecture

HttpPlugin (transport) → only handles HTTP server/routing/auth
                      → emits ICoreActivity (minimal protocol knowledge)
                      → just passes body payload to app

ActivitySender (NEW)  → dedicated class for sending activities
                     → receives injected, reusable Client
                     → handles all send/stream logic
                     → private to App class

ActivityContext       → uses ISender now (which is not a plugin) 

In this PR, I am mainly decoupling responsibilities of HttpPlugin from being BOTH a listener AND a sender, to being just a listener. The sender bit is now separated to a different ActivitySender class. Other than better code organization, the main thing this lets us do is not require the app to run to be able to send proactive messages. This is a huge plus point because now the App can be used in scenarios where it doesn't necessarily need to listen to incoming messages (like agentic notifications!)

Major Decisions

1. Created ActivitySender Class

• Centralized all activity sending logic
• Receives reusable Client in constructor (no per-send instantiation)
• Private to App class - internal implementation detail
• Provides send() and createStream() methods
• Separate from HttpPlugin

2. Introduced ICoreActivity Interface

• Minimal fields transport layer needs: serviceUrl, id, type
• Extensible via [key: string]: any for protocol-specific fields
• Transport plugins work with this instead of full Activity type. So it's easier to create these.
• Parsing to Activity happens in app.process.ts now, NOT in HttpPlugin.

3. Removed ISender Interface

• No longer needed - plugins don't send activities
• Plugins only handle transport (receiving requests)
• Breaking change, but simplifies plugin architecture. This pattern wasn't documented (intentionally) because the design was subject to change. So it should be okay hopefully to change this.

Breaking Changes

For Plugin Authors:

1. ISender removed - Custom plugins should implement IPlugin only
2. IActivityEvent changed - Now has body: ICoreActivity instead of activity: Activity

PR Dependency Tree

• PR Simplify HTTP Plugin architecture #424 👈
  • PR Introduce HttpServer (and begin deprecating HttpPlugin) #433
    • PR Upgrade to express v5 #442

This tree was auto-generated by Charcoal