Support QoS for writes about keytransparency

[mhutchinson]

If you want to support processing messages not necessarily in the order they are sent to the KT input queue via gRPC, then you'll need some mechanism to stack-rank messages for processing.

I'm assuming a goal is that KT evolves to to the point where you can run KeyTransparency-as-a-service (i.e. multi-tenant). That seems to be the reasoning behind multiple directory IDs. This rules out running client-defined prioritization code within the KT server.

So there is the requirement that a writer to KT can pass in advice on the QoS tier for a message being written, and that KT can interpret this advice in a well-defined way which is consistent across all of its tenants. This advice could be:

• log ID
• explicit enum
• a timestamp that the message should be merged before

There are a number of strategies that could be implemented given each of these implementation paths. These are listed in order of how decoupled they are from the implementation. Where to pick on this spectrum isn't clear without zooming out to consider the whole of the KT API when considered as a service. Happy to advise on this if my experience is useful, but I won't be able to justify prioritizing time to lead this work given my current focus.