Wez Furlong 64fac57d09 formalize provider information for queues, add to logs ...

The recent changes to enable shaping based on a pattern-matched provider
are nice, but it is important to be able to observe their effects.

So far this has been awkward because the provider concept was purely a
function of the logic in the shaping.lua file and nothing else.

This commit introduces the concept of a `provider_name` field in
both the EgressPathConfig and QueueConfig structs.

The idea is that the `get_egress_path_config` and `get_queue_config`
events are free to populate this field as makes sense to them, so that
the core is then aware of which provider is associated with those
queues.

Once we have that data, we're then able to log it as a field in the
JsonLogRecord.

That is what this commit does. There are some interesting points to note
about the implementation here:

1. shaping.lua will implicitly assign provider_name if it matches
   any providers.

2. It is technically possible for a shaping.toml to define multiple
   providers that match a given domain. In that circumstance, the
   last matching provider is the winner when it comes to assigning
   the provider_name field.

3. In order to populate the provider_name in the queue.lua helper,
   we need to be able to call out to the get_egress_path_config
   event handlers, so a new kumo.invoke_get_egress_path_config
   has been added to support that.

4. kumo.invoke_get_egress_path_config isn't 100% done: there are
   a couple of fields (openssl related) that don't have a defined
   serializer, so we're simply omitting them.  The function is
   "done enough" for the purposes of retrieving the provider_name

refs: https://github.com/KumoCorp/kumomta/issues/276

2024-09-12 20:51:00 -07:00

..

src

formalize provider information for queues, add to logs

2024-09-12 20:51:00 -07:00

Cargo.toml

update vaultrs dep

2024-05-23 08:32:54 -07:00