add feature tracking for cbor protocol

[lucix-aws]

Add feature metrics tracking for CBOR clients. Not actually used by any service right now, but you can see the codegen results in the cbor protocol test.

[Madrigal]

While this is named Feature it's really only for CBOR metrics due to the getAddMiddleware(). We should either make the CBOR metrics extend from this or rename this

[lucix-aws]

What about the getAddMiddleware constrains it to CBOR? The feature ID variant is passed in.

[Madrigal]

Yeah, my point is that the class name is generic but the functionality is not, so we should either make it generic or name it accordingly

[lucix-aws]

The functionality of Feature is generic though - it's just that CBOR is the only thing using it. You could add any other static feature to the FEATURES list in the future.

e.g.

    private static final List<Feature> FEATURES = List.of(
           new Feature("ProtocolRPCV2CBOR", (model, service) -> service.hasTrait(Rpcv2CborTrait.class)),
           new Feature("ProtocolSparrowhawk", (model, service) -> etc())
    );

[Madrigal]

OK I'm dumb, I kept reading the functionality of getAddMiddleware as specific to CBOR since the code always calls the same middleware, but this is exactly what we want since this middleware is generic

[Madrigal]

We're missing a changelog (should we add automation to check this?)

[lucix-aws]

We're missing a changelog (should we add automation to check this?)

I left a changelog out because it doesn't actually have any effect on released source. A changelog at the root module here would have just meant a new root module => service module churn because everything has to update to pull it in.

[Madrigal]

Only comment that we'll discuss

I left a changelog out because it doesn't actually have any effect on released source. A changelog at the root module here would have just meant a new root module => service module churn because everything has to update to pull it in.

I don't think our automation can handle a no changelog change IIRC