Update GCP agents to current Go versions

[jepio]

Update GCP agents to current Go versions

• Import ebuilds from COS (Container Optimized OS)
• Patch for compatibility with our eclass
• Replace oem-gce contents
• Remove unused ebuilds

TODO:

• Quality Assurance (ask a GCP user to test the image)
• Check if we need to introduce an enable-os-login service that users can mask
• Check if we need /var/ -> /var/lib patch (we do), and figure out if we want to patch it use a symlink.

How to use

[ describe what reviewers need to do in order to validate this PR ]

Testing done

[Describe the testing you have done before submitting this PR. Please include both the commands you issued as well as the output you got.]

• Changelog entries added in the respective changelog/ directory (user-facing change, bug fix, security fix, update)
• Inspected CI output for image differences: /boot and /usr size, packages, list files for any missing binaries, kernel modules, config files, kernel modules, etc.

[pothos]

Quality Assurance (ask a GCP user to test the image)

I think kola spawn could be of use for that when started the same way Jenkins starts kola run

[github-actions]

Build action triggered: https://github.com/flatcar/scripts/actions/runs/8523902983

[pothos]

I think we need to add an ExecStartPre to one of the services to clean up state created from the old setup-oem.service.
It had this:

ExecStart=-/usr/bin/ln --symbolic --force /usr/share/gce/hosts /etc/hosts
ExecStart=-/usr/bin/ln --symbolic /usr/share/gce/google-cloud-sdk.sh /etc/profile.d/google-cloud-sdk.sh

Maybe remove /etc/profile.d/google-cloud-sdk.sh but what about /etc/hosts? Would the new software set it up or doesn't it need a special setup anymore? If it should be reverted to Flatcar's defaults then the removal would have to be done in the upperdir but since this is not recommended during use, one can rather rely on the duplicate cleanup logic in the initrd and reset the file by copying from /usr/share/flatcar/etc/hosts so that after a reboot this manual upcopy should be gone.

[jepio]

Quality Assurance (ask a GCP user to test the image)

I think kola spawn could be of use for that when started the same way Jenkins starts kola run

I did try kola spawn, and tested the oslogin functionality but I'm not confident that i managed to cover everything. I'm not super familiar with GCP.

[jepio]

I think we need to add an ExecStartPre to one of the services to clean up state created from the old setup-oem.service. It had this:

ExecStart=-/usr/bin/ln --symbolic --force /usr/share/gce/hosts /etc/hosts
ExecStart=-/usr/bin/ln --symbolic /usr/share/gce/google-cloud-sdk.sh /etc/profile.d/google-cloud-sdk.sh

Maybe remove /etc/profile.d/google-cloud-sdk.sh but what about /etc/hosts? Would the new software set it up or doesn't it need a special setup anymore? If it should be reverted to Flatcar's defaults then the removal would have to be done in the upperdir but since this is not recommended during use, one can rather rely on the duplicate cleanup logic in the initrd and reset the file by copying from /usr/share/flatcar/etc/hosts so that after a reboot this manual upcopy should be gone.

Yes, we need to think a bit more about what happens when upgrading.