Match event listener names to event type names in fdc3 for web schemas

[kriswest]

Describe your change

The FDC3 for Web message schema for requesting the addition of an event listeners to a private channel use the names of the deprecated event handlers (e.g. onAddContextListener) rather than the type of the event that is fired (e.g. addContextListener), which are defined at:
https://fdc3.finos.org/docs/next/api/ref/Events#privatechanneleventtypes

For the message definition, see:

• https://fdc3.finos.org/schemas/next/api/privateChannelOnAddContextListenerEvent.schema.json)
• https://fdc3.finos.org/schemas/next/api/common.schema.json

This will often require translation in implementations and should simply use the event types instead.

Related Issue

Part of #1429

Contributor License Agreement

• I acknowledge that a contributor license agreement is required and that I have one in place or will seek to put one in place ASAP.

Review Checklist

• Issue: If a change was made to the FDC3 Standard, was an issue linked above?
• N/A (small adjustment to unreleased feature) CHANGELOG: Is a CHANGELOG.md entry included?
• API changes: Does this PR include changes to any of the FDC3 APIs (DesktopAgent, Channel, PrivateChannel, Listener, Bridging)?
  • Docs & Sources: If yes, were both documentation (/docs) and sources updated?
    
    JSDoc comments on interfaces and types should be matched to the main documentation in /docs
  • Conformance tests: If yes, are conformance test definitions (/toolbox/fdc3-conformance) still correct and complete?
    
    Conformance test definitions should cover all required aspects of an FDC3 Desktop Agent implementation, which are usually marked with a MUST keyword, and optional features (SHOULD or MAY) where the format of those features is defined
  • Schemas: If yes, were changes applied to the Bridging and FDC3 for Web protocol schemas?
    
    The Web Connection protocol and Desktop Agent Communication Protocol schemas must be able to support all necessary aspects of the Desktop Agent API, while Bridging must support those aspects necessary for Desktop Agents to communicate with each other
    • If yes, was code generation (npm run build) run and the results checked in?
      
      Generated code will be found at /src/api/BrowserTypes.ts and/or /src/bridging/BridgingTypes.ts
• Context types: Were new Context type schemas created or modified in this PR?
  • Were the field type conventions adhered to?
  • Was the BaseContext schema applied via allOf (as it is in existing types)?
  • Was a title and description provided for all properties defined in the schema?
  • Was at least one example provided?
  • Was code generation (npm run build) run and the results checked in?
    
    Generated code will be found at /src/context/ContextTypes.ts
• Intents: Were new Intents created in this PR?
  • Were the intent name prefixes and other naming conventions & characteristics adhered to?
  • Was the new intent added to the list in the Intents Overview?

[netlify]

✅ Deploy Preview for fdc3 ready!

Name	Link
🔨 Latest commit	e9890d4
🔍 Latest deploy log	https://app.netlify.com/sites/fdc3/deploys/675187b4f4db29000882b0bb
😎 Deploy Preview	https://deploy-preview-1459--fdc3.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[kriswest]

Approved at SWG #1458

[Roaders]

👍this will simplify some of our code quite a bit!

[kemerava]

LGTM

[kriswest]

@novavi This is also ready to go and implemented in fdc3-for-web-getAgent-refactor. The handling is implemented in: https://github.com/finos/FDC3/blob/fdc3-for-web-impl-getAgent-refactor/packages/fdc3-agent-proxy/src/listeners/PrivateChannelEventListener.ts

No need to fully digest that source as the proposal is just to change the strings that indicate the different events in the DACP. Again this should be ready to merge and update the docs.

[novavi]

LGTM