Update machine-controller to v1.58.0 and OSM to v1.4.0

What this PR does / why we need it:

Update machine-controller to v1.58.0
Update operating-system-manager (OSM) to v1.4.0

What type of PR is this?
/kind cleanup
Does this PR introduce a user-facing change? Then add your Release Note here:
- Update machine-controller to v1.58.0
- Update operating-system-manager (OSM) to v1.4.0

Documentation:
NONE

/assign @kron4eg

/lgtm
/approve


Feature request: Disable compression

I got everything running on the same host which makes compressing/decompressing a waste of cpu time.
An option to disable gzip would be appreciated.

fixed


Fix input transform destructor

Changelog entry
...
Changelog category

Not for changelog (changelog entry is not required)

Additional information
...

Backgrace with last patch reverted/unapplied:
E   VERIFY failed (2024-08-16T15:38:56.382376+0300):
E   ydb/library/yql/minikql/mkql_alloc.h:378
E   MKQLFreeFastWithSize(): requirement state failed
E
E   0. /-S/util/system/yassert.cpp:83: NPrivate::InternalPanicImpl(int, char const*, char const*, int, int, int, TBasicStringBuf<char, std::__y1::char_traits<char>>, char const*, unsigned long) @ 0xAAAC44C
E   1. /-S/util/system/yassert.cpp:55: NPrivate::Panic(NPrivate::TStaticBuf const&, int, char const*, char const*, char const*, ...) @ 0xAAA6176
E   2. /-S/ydb/library/yql/minikql/mkql_alloc.h:378: NKikimr::NMiniKQL::MKQLFreeFastWithSize(void const*, unsigned long, NKikimr::NMiniKQL::TAllocState*, NKikimr::NMiniKQL::EMemorySubPool) @ 0xA3EEEEC
E   3. /home/yumkam7/src/ydb-fork-4/ydb/library/yql/public/udf/udf_value_inl.h:46: NYql::NUdf::IBoxedValue1::UnRef() @ 0x1A76F66A
E   4. /home/yumkam7/src/ydb-fork-4/ydb/library/yql/public/udf/udf_value_inl.h:660: NYql::NUdf::TUnboxedValuePod::UnRef() const @ 0x1A76F66A
E   5. /home/yumkam7/src/ydb-fork-4/ydb/library/yql/public/udf/udf_value_inl.h:359: NYql::NUdf::TUnboxedValue::~TUnboxedValue() @ 0x1A76F66A
E   6. /home/yumkam7/src/ydb-fork-4/ydb/library/yql/dq/actors/input_transforms/dq_input_transform_lookup.cpp:20: NYql::NDq::(anonymous namespace)::TInputTransformStreamLookupBase::~TInputTransformStreamLookupBase() @ 0x1A76F66A
E   7. /home/yumkam7/src/ydb-fork-4/ydb/library/yql/dq/actors/input_transforms/dq_input_transform_lookup.cpp:254: NYql::NDq::(anonymous namespace)::TInputTransformStreamLookupNarrow::~TInputTransformStreamLookupNarrow() @ 0x1A77260D
E   8. /-S/ydb/library/actors/core/mailbox.cpp:396: NActors::TMailboxHeader::CleanupActors(NActors::TMailboxHeader::TMailboxActorPack::EType&, NActors::TMailboxHeader::TActorsInfo&) @ 0xB9F5751
E   9. /-S/ydb/library/actors/core/mailbox.cpp:414: NActors::TMailboxHeader::CleanupActors() @ 0xB9F41C4
E   10. /-S/ydb/library/actors/core/mailbox.cpp:61: bool NActors::CleanupMailboxLine<NActors::TMailboxTable::THTSwapMailbox>(unsigned char*, unsigned char*) @ 0xB9F41C4
E   11. /-S/ydb/library/actors/core/mailbox.cpp:120: NActors::TMailboxTable::Cleanup() @ 0xB9F3D5F
E   12. /-S/ydb/library/actors/core/cpu_manager.cpp:105: NActors::TCpuManager::Shutdown() @ 0xB999A6E
E   13. /-S/ydb/library/actors/core/actorsystem.cpp:330: NActors::TActorSystem::Stop() @ 0xB9971B7
E   14. /home/yumkam7/src/ydb-fork-4/ydb/core/driver_lib/run/run.cpp:1774: NKikimr::TKikimrRunner::KikimrStop(bool) @ 0x153709A9
E   15. /-S/ydb/core/driver_lib/run/main.cpp:50: NKikimr::MainRun(NKikimr::TKikimrRunConfig const&, std::__y1::shared_ptr<NKikimr::TModuleFactories>) @ 0x14E731F9
E   16. /-S/ydb/core/driver_lib/cli_utils/cli_cmds_server.cpp:51: NKikimr::NDriverClient::TClientCommandServer::Run(NYdb::NConsoleClient::TClientCommand::TConfig&) @ 0x1530BDEB
E   17. /-S/ydb/core/driver_lib/cli_utils/cli_cmds_root.cpp:72: NKikimr::NDriverClient::NewClient(int, char**, std::__y1::shared_ptr<NKikimr::TModuleFactories>) @ 0x14EA6757
E   18. /-S/ydb/core/driver_lib/run/main.cpp:148: NKikimr::Main(int, char**, std::__y1::shared_ptr<NKikimr::TModuleFactories>) @ 0x14E74DE2
E   19. /-S/ydb/core/driver_lib/run/main.cpp:198: ParameterizedMain(int, char**, std::__y1::shared_ptr<NKikimr::TModuleFactories>) @ 0x14E75D99
E   20. /-S/ydb/apps/ydbd/main.cpp:24: main @ 0xA9F07EA
E   21. ../sysdeps/nptl/libc_start_call_main.h:58: __libc_start_call_main @ 0x7DB376029D8F
E   22. ../csu/libc-start.c:392: __libc_start_main_impl @ 0x7DB376029E3F
E   23. ??:0: ?? @ 0x9D64028

Not a proper fix.
There are (documented) assumption that PassAway() is always called (with proper allocator installed).
And it seems message that should trigger PassAway() is actually sent:
0. /home/yumkam7/src/ydb-fork-4/ydb/library/yql/dq/actors/input_transforms/dq_input_transform_lookup.cpp:164: NYql::NDq::(anonymous namespace)::TInputTransformStreamLookupBase::PassAway() @ 0x1A76F836
1. /-S/ydb/library/yql/dq/actors/compute/dq_compute_actor_impl.h:473: NYql::NDq::TDqComputeActorBase<NYql::NDq::TDqAsyncComputeActor, NYql::NDq::TComputeActorAsyncInputHelperAsync>::Terminate(bool, NYql::TIssues const&) @ 0x1A7F7DAB
2. /-S/ydb/library/yql/dq/actors/compute/dq_compute_actor_impl.h:1138: NYql::NDq::TDqComputeActorBase<NYql::NDq::TDqAsyncComputeActor, NYql::NDq::TComputeActorAsyncInputHelperAsync>::HandleExecuteBase(TAutoPtr<NActors::TEventHandle<NYql::NDq::TEvDq::TEvAbortExecution>, TDelete>&) @ 0x1A7F36E2
3. /-S/ydb/library/yql/dq/actors/compute/dq_compute_actor_impl.h:223: void NYql::NDq::TDqComputeActorBase<NYql::NDq::TDqAsyncComputeActor, NYql::NDq::TComputeActorAsyncInputHelperAsync>::StateFuncWrapper<&NYql::NDq::TDqAsyncComputeActor::StateFuncBody(TAutoPtr<NActors::IEventHandle, TDelete>&)>(TAutoPtr<NActors::IEventHandle, TDelete>&) @ 0x1A7F9AB2
4. /-S/ydb/library/actors/core/executor_thread.cpp:251: NActors::TGenericExecutorThread::TProcessingResult NActors::TGenericExecutorThread::Execute<NActors::TMailboxTable::THTSwapMailbox>(NActors::TMailboxTable::THTSwapMailbox*, unsigned int, bool) @ 0xB9BFB57
5. /-S/ydb/library/actors/core/executor_thread.cpp:440: NActors::TGenericExecutorThread::ProcessExecutorPool(NActors::IExecutorPool*)::$_0::operator()(unsigned int, bool) const @ 0xB9B7021
6. /-S/ydb/library/actors/core/executor_thread.cpp:493: NActors::TGenericExecutorThread::ProcessExecutorPool(NActors::IExecutorPool*) @ 0xB9B6A19
7. /-S/ydb/library/actors/core/executor_thread.cpp:524: NActors::TExecutorThread::ThreadProc() @ 0xB9B78BF
8. /-S/util/system/thread.cpp:244: (anonymous namespace)::TPosixThread::ThreadProxy(void*) @ 0xAAB0B5E
9. ./nptl/pthread_create.c:442: start_thread @ 0x7C25FC494AC2
10. ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81: ?? @ 0x7C25FC52684F

... but sometimes it is not processed, there are no wait for it to be processed, and after destructor is called, which leads to above VERIFY.

To summarize: real problem is CA::Terminate is not always called before destructors.
This affects not only InputTransform, but also Sinks and Sources (that also requires PassAway to be called).
For common sinks/sources window when it fires is small, for StreamlookupInputTransform -- this window is from Bootstrap and to PassAway (that is, every time CA::Terminate is not called and streamlookup was used, it will die on VERIFY or sigsegv in desrructor)


Improve security hygiene and documentation

I noticed prometheus-adapter is lacking in security documentation. I'm thinking about something similar to what was done in https://github.com/kubernetes/kube-state-metrics/issues/2274 for Security Slam - Kubernetes Lightning Round.
Would you like to do this for prometheus-adapter? This means:

Generating an SBOM automatically when a new release is tagged, so that users have a better understanding of whether or not they're affected by a particular vulnerability
Generating SLSA/provenance attestation automatically for each new release, so that users can verify the authenticity and trustworthiness of the build process
Initializing VEX feed and generating OpenVEX data on each release, so that users have a better understanding of which vulnerabilities present a genuine risk
Setting up CLOMonitor tracking and following-up on any security checks

I believe this relates to https://github.com/kubernetes/sig-release/blob/193a3cdf8d73e0888c7f6829eea3716918a5af4a/roadmap.md

/assign @ricardoapl
/triage accepted

Maybe we can close this since prometheus-adapter will be archived?
/cc @dgrisonnet

Yes :+1:


bug: Can't run vscode-neovim in react-native project

Check the following:

[X] I have checked the behavior after setting "vscode-neovim.neovimClean" in VSCode settings.
[X] I have read the vscode-neovim docs.
[X] I have searched existing issues.

Neovim version (nvim -v)
0.10.0
Operating system/version
ubuntu 24
Describe the bug
I'm not sure why I can't run vscode-neovim in my React Native project.
Steps To Reproduce
The issue is strange because "Neovim was disconnected", or sometimes I can't use hjkl or switch modes (i, a, v). However, it works perfectly fine in Java or Golang projects.
Expected Behavior
Run vscode-neovim plugins in react native project.

Please search the existing issues first.


Fix create var code action in async send action

Purpose
$subject
Fixes #36078
Approach
The diagnostic property includes the WorkerSymbol instead of the FutureTypeSymbol. This cause a class cast exception. Fixed it.
Samples

Provide high-level details about the samples related to this feature.

Remarks

List any other known issues, related PRs, TODO items, or any other notes related to the PR.

Check List

[x] Read the Contributing Guide
[ ] Updated Change Log
[ ] Checked Tooling Support (#)
[x] Added necessary tests

[x] Unit Tests
[ ] Spec Conformance Tests
[ ] Integration Tests
[ ] Ballerina By Example Tests

[ ] Increased Test Coverage
[ ] Added necessary documentation

[ ] API documentation
[ ] Module documentation in Module.md files
[ ] Ballerina By Examples

@dulajdilshan At org.wso2.ballerinalang.compiler.semantics.analyzer.CodeAnalyzer#dlog, we are setting the WorkerSymbol instead of FutureTypeSymbol as the diagnostic property. In other cases (of variable assignment required), it is setting the type symbol. But only in this case, it's setting the symbol itself. Was this intentional?
At LS, this causes a CCE when we try to get the diagnostic property assuming it's of type TypeSymbol.

@dulajdilshan At org.wso2.ballerinalang.compiler.semantics.analyzer.CodeAnalyzer#dlog, we are setting the WorkerSymbol instead of FutureTypeSymbol as the diagnostic property. In other cases (of variable assignment required), it is setting the type symbol. But only in this case, it's setting the symbol itself. Was this intentional?
At LS, this causes a CCE when we try to get the diagnostic property assuming it's of type TypeSymbol.

LS is set-up to check for TypeSymbol when it comes to ASSIGNMENT_REQUIRED?

@dulajdilshan as discussed offline, let's use the existing diagnostic property and proceed.


BPDM KIT Adjustments 24.05

Description
KIT Adaption View; high level comprehensive overview of interaction of VAS services and GR
Impact

Additional information

[ ] I'm willing to contribute to this feature

Discussed in open refinement -> ready for planning (status Backlog)

Done


Fix TWAI on ESP32

Thank you for your contribution!
We appreciate the time and effort you've put into this pull request.
To help us review it efficiently, please ensure you've gone through the following checklist:
Submission Checklist 📝

[x] I have updated existing examples or added new ones (if applicable).
[x] I have used cargo xtask fmt-packages command to ensure that all changed code is formatted correctly.
[x] My changes were added to the CHANGELOG.md in the proper section.
[x] I have added necessary changes to user code to the Migration Guide.
[x] My changes are in accordance to the esp-rs API guidelines

Extra:

[x] I have read the CONTRIBUTING.md guide and followed its instructions.

Pull Request Details 📖
Description
A few issues here and there
cc #324
Testing
Ran HIL test locally on both 32 and S2.

I noticed you added self test example to the issue checklist, do you see much value in doing that?

What do you mean I added it? 🤔

Ah sorry this diff made it look like you added it and I didn't go back and check the other edits


Add test case for ThreadPoolExecutorUtil

Fixes #1330
Changes proposed in this pull request:

Add test case for ThreadPoolExecutorUtil

Please check why there is no change in unit test coverage.
Refer to this PR: https://github.com/opengoofy/hippo4j/pull/1353