Implement Chrome 133+ support

[BRUHItsABunny]

Since Chrome 133 the TLS fingerprint is changing due to this feature:
https://chromestatus.com/feature/5149147365900288

I found that others are also running into this problem here: #330

It looks like a "full" implementation might be bigger than just extending the current application settings extension, as per another implementation here:
bogdanfinn/utls@fe91add

Opening this PR as a draft to discuss how we should move forward on this, I've also implemented this for the time being as it might be enough to address this (at least for my use case)

[Juktong]

Since the previous codepoints are coded in file exttype_values.go, it would be a good idea to also update it as well.

[BRUHItsABunny]

I noticed some TLS errors especially on Google domains while using my branch. I have updated it to support the new application settings code point in the ECH as well to fix those errors.

[mingyech]

Looks good, added some suggestions

[RonaldinhoL]

rename ApplicationSettingsExtension to applicationSettingsExtension break my exist custom spec

[RonaldinhoL]

Just duplicating the ApplicationSettingsExtension would be cleaner. These changes force unnecessary updates to too many spec settings.

[BRUHItsABunny]

I understand, some of my own modules also broke with those changes and wasn't sure if that was the expectation with the approach that was requested.
I made some changes that achieve both goals at the same time (1 only 1 place to implement the extension being written to the wire, 2 no breakages with the pre-existing patterns that expect the SupportedProtocols slice to be available and exported)

[mingyech]

Ooo yeah we should be careful with compatibility, thanks for pointing out @RonaldinhoL

@BRUHItsABunny This new change looks good though, looks like nothing will be broken

[RonaldinhoL]

Ooo yeah we should be careful with compatibility, thanks for pointing out @RonaldinhoL

@BRUHItsABunny This new change looks good though, looks like nothing will be broken

this not work for me, my specs are defined out of utls lib, applicationSettingsExtension is not exposed.
just as I said, in order to reuse a few lines of code from applicationSettingsExtension, you've ended up requiring modifications to dozens of already-defined specs. This makes absolutely no sense and just makes the code look messy.
btw if u want to merge to master, you'd better make a squash commit.

[mingyech]

I don't think it will require outside changes though? applicationSettingsExtension will be auto initialized with the exported versions

[BRUHItsABunny]

Could you provide an example of what you are trying to do?
Here is an example of what broke for me (which was copied from somewhere else so I expect it to be more prevalent):
https://github.com/BRUHItsABunny/gOkHttp-ja3spoof/blob/82382ec2ed1f3d51e50cb4479b0142e92d8ee911/transportv2.go#L123

With the new changes this doesn't panic anymore.
Is there any reason you are trying to instantiate the unexported embedded struct? It's not a pointer ref so when you instantiate the outer struct utls.ApplicationSettingsExtension the Go runtime should automatically instantiate it the embedded one as well.

[mingyech]

Added 4241c5b to make clear that this will not break backward compatibility, but let me know if there's something else broken by this

btw if u want to merge to master, you'd better make a squash commit.

Good idea yeah I'll do some squashing when merging

[BRUHItsABunny]

Thanks for carrying it over the finish line @mingyech