Try mangling _private service props

[mjbvz]

This enables property mangling for properties with names such as _someService. This is designed to only touch properties that we are confident can be mangled safely (in this case, any private services)

This results in a very small (0.75%) reduction in the size of workbench.js. For the future:

• If we mangle every this.someService property, we could reduce the bundle size by 4%

• If we mangle every this._privateProp properties, we could reduce the bundle size by 6%. We could likely save more by adopting _ names for private props in more places

• If we mangle every property, we'd reduce by bundle size by 40% (this is only theoretically, as doing this completely breaks the code)

[jrieken]

Change looks good, unsure about the CI failure tho

[jrieken]

Could this be failing because folks use _ for protected services that are now being mangled?

[mjbvz]

@jrieken Where were seeing the failures? I created a private build (13c08c6). It failed for unrelated reasons. I will kick off another test build though

I also sanity checked the bits that succeeded and everything seems to run ok

[jrieken]

Sorry, saw the wrong/bogous build failure. Anyways, I do believe there is an inherent risk with this or I am missing something. We have many injected services using _fffService that are protected properties (sample). Aren't we breaking those with the mangle?

As a related FYI: I have updated #165259 to only check for _\w+Service which is a smaller, but not small, list. This build has a list of protected properties that use the service naming pattern: https://dev.azure.com/vscode/a4cdce18-a05c-4bb8-9476-5d07e63bfd76/_build/results?buildId=77891

[mjbvz]

@jrieken My understanding of property mangling is that it operates on the entire bundle (not per file). If a protected property is managed, all the subclasses using it should also get updated to use the new name. I will confirm this is happening correctly in our codebase

[mjbvz]

Closing in favor of #166126