Remove plugin_context_id from callbacks.

[PiotrSikora]

No description provided.

[PiotrSikora]

(Mostly opening this for the discussion)

[mpwarres]

Just to understand better, is the rationale for this that the plugin already knows the context ID from on_configure, so passing it again in subsequent callbacks doesn't provide much value, or that the plugin context ID itself isn't used for much and therefore doesn't need to be passed?

[PiotrSikora]

the plugin already knows the context ID from on_configure, so passing it again in subsequent callbacks doesn't provide much value

No, there can be multiple plugin instances running at the same time (either config reload or multiple instances with different configurations running using same vm_id), so a plugin_context_id from past invocation of on_configure doesn't mean anything in subsequent callbacks (unless you're in a single plugin instance WasmVM, but then plugin_context_id is meaningless).

It's purely about the consistency.

Right now, we create association between streams (stream_id) and their plugin instance (plugin_context_id) when creating a new resource (on_create_context), and stream callbacks (on_http_request, on_downstream_data, etc.) don't carry the extra plugin_context_id.

On the other hand, callbacks for callouts and queues are called with an explicit plugin_context_id as their first argument, and since those resources are first created inside plugins, they can store the association themselves if needed.

I think the original reason for plugin_context_id in those was that e.g. HTTP callback could be cancelled on the plugin side (e.g. if the "main" request timed out), and we would later receive a callback for it, and with only call_id (that's now invalid), we couldn't tell which plugin instance that callback was destined for... But I think that we silently drop those at the SDK level nowadays...