User agent

[alextwoods]

Description of changes:
Add UserAgent header to requests in generated clients using runtime plugins with separate generic and AWS specific logic.

This change adds a generic (non-aws) plugin that adds a base UserAgent object to the interceptor context that allows other interceptors to add data to the user agent. This is required because the user agent string MUST follow a defined order so we cannot simply append values to the header. The generic interceptor also adds a modify_before_sign interceptor which sets the user agent header from the UserAgent object on the context.

The AWS specific plugin must be generated per service client to give us access to the service library's version and the service ID. The interceptor just adds data to the UserAgent context object.

The UserAgent class logic is largely borrowed from botocore's UserAgent.

The advantages of this approach:

• UserAgent header MUST follow a defined order. Adding a 'user-agent' object on context allows different interceptors to easily add data to the user agent without breaking the order or having to parse/rebuild the string.
• This provides easy implementation of business metrics down the road.
• Uses existing extension points (interceptor/plugin) to modify requests rather than adding additional logic to the core execution pipeline.

Cons/Issues:

• We need access to certain config values during the request. The interceptor context does not give access to config. We can access a version of config when the plugin is called, but other plugins (including operation level plugins) could modify it after.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[JordonPhillips]

You should run pyupgrade --py312-plus on all this, it'll resolve most of the typing and syntax issues I've called out.

As far as this being in AWS, I don't agree. I think almost all of this can and should be generic. The only real exception would be the app id and execution env, but those could be appended in a separate interceptor

[JordonPhillips]

Why did you move this into Java?

[alextwoods]

To get the client library version and service id - since both of those are specific to the generated client.

The alternative would be to add that information to the interceptor context (or potentially to use some python metaprogramming hacks?).

Do you have thoughts or preferences between those? (or maybe another obvious way I'm missing to get client library version and service id)

[JordonPhillips]

Ah yeah the service id isn't available right now because we're not writing out service schemas, and thus those traits aren't present.

[alextwoods]

I think even with service schemas we'd still need some way for a generic (ie, non codegen) interceptor or plugin to access it. Though there are a few ways we could do that - such as adding it to the interceptor context or the config? Theres probably other pythonic metaprogramming tricks as well (get the caller's namespace and search it?)

[nateprewitt]

I think this is probably my last round of comments, otherwise things look good!

[nateprewitt]

Also looks like the test_environment tests may not have everything properly mocked:

AssertionError: assert 'md/arch#arm64' in 'python/1.2.3 ua/2.1 os/linux#5.4.228-131.415.AMZN2.X86_64 md/arch#x86_64 lang/python#4.3.2 md/pyimpl#Cpython'

It looks like you tested arm64 locally, but GHA is running on x86_64.

[JordonPhillips]

The formatter has truly failed here... oh well

[alextwoods]

Yeah - I had a bit of a fight with it trying to make this a little less garbage. Made it slightly better, but still don't love it.

[JordonPhillips]

T is intended for references, not declarations. Why was this change made?

[alextwoods]

Reverted to $L for the decleration - Had done it without thinking since its using the symbol as an argument.

[JordonPhillips]

This could be done directly in generateInits. I'm refactoring this in a separate PR though so it's fine to have it here for now.