initialize: make default user configurable via CLI flag

[Prat260104]

Why

While exploring the codebase, I came across this TODO comment in initialize/user_data.go:

// TODO(gabriel-samfira): make the default user configurable?

The "core" username was hardcoded in three places across the codebase (initialize/config.go and initialize/user_data.go) when applying SSH keys from cloud-config. Because of this, Flatcar derivatives or custom images that use a different default username couldn't rely on ssh_authorized_keys working out of the box.

This PR implements the TODO by making the default user configurable.

What changed

• Added a DefaultUser constant ("core") and a new --default-user CLI flag in coreos-cloudinit.go

• Added a defaultUser field to the Environment struct, along with a DefaultUser() accessor method

• Replaced the hardcoded "core" references with env.DefaultUser() / ud.env.DefaultUser() in config.go and user_data.go

• Renamed ApplyCoreUserSSHKeys() → ApplyDefaultUserSSHKeys() to reflect the new behavior

• Updated Documentation/cloud-config.md and README.md to document the new flag

• Added test coverage:

  • TestEnvironmentDefaultUser — verifies default and custom user values on Environment
  • TestFindSSHKeysWithDefaultUser, TestFindSSHKeysWithCustomDefaultUser, TestFindSSHKeysWithAdditionalKeys — verify SSH key resolution behavior with both default and custom users
  • Added initialize/testdata/custom_user_cloudconfig.txt as test fixture data

Backward compatibility

The flag defaults to "core", so existing behavior remains unchanged for anyone who doesn't pass --default-user.

Testing

• go build ./... — passes
• go vet ./... — passes
• go test ./... — all tests pass except for a pre-existing failure in datasource/vmware (TestOvfTransport, nil pointer panic). I confirmed that the same test also fails on origin/main without this change, so it appears to be unrelated to this PR.
• gofmt -l . — clean (only vendored files were reported, which were not touched in this PR)

[Prat260104]

Hi @John15321 sir ,
Just a follow up regarding this ,
it might get buried during PR spams before application period of LFX fall term

[Prat260104]

Hi @John15321 @tormath1 @t-lo @dongsupark
Just a follow up regarding review on this PR .

[LexiNadolski]

@Prat260104 Please be mindful when tagging maintainers for any reviews, especially now with an influx of so many contributions over the last two weeks. We are working to address things as time allows.

We covered the updated rule in the community guidelines on Discord 30 July, and it's also in the Linux Foundation Mentorship Standards of Excellence under Respect Maintainer Time. https://docs.linuxfoundation.org/lfx/mentorship/standards-of-excellence.

Thank you for understanding.

[Prat260104]

@Prat260104 Please be mindful when tagging maintainers for any reviews, especially now with an influx of so many contributions over the last two weeks. We are working to address things as time allows.

We covered the updated rule in the community guidelines on Discord 30 July, and it's also in the Linux Foundation Mentorship Standards of Excellence under Respect Maintainer Time. https://docs.linuxfoundation.org/lfx/mentorship/standards-of-excellence.

Thank you for understanding.

Hi @LexiNadolski mam,

I completely understand the influx of PRs due to the upcoming LFX Fall term, and I apologize if my mention came across as inconsiderate.

I only tagged the mentors after noticing that some newer PRs had already been reviewed. I assumed my PR might have been buried in the queue or possibly missed. I wasn't trying to rush the review process or spam mentions.

I've intentionally limited myself to opening a single PR and have been waiting for its review before submitting more, precisely to avoid adding unnecessary load on the maintainers.

Thank you for the clarification.

[LexiNadolski]

@Prat260104 Thanks for the thoughtful reply and for sticking to one PR at a time. That's genuinely the right approach and it doesn't go unnoticed.

One thing to keep in mind: review order isn't FIFO. Things get picked up by area, urgency, and who has capacity, so a newer PR moving first doesn't mean yours was missed. Tagging maintainers to re-surface a PR is what the 30 July community guidelines on Discord and Respect Maintainer Time in the LF Standards of Excellence ask contributors to avoid: https://docs.linuxfoundation.org/lfx/mentorship/standards-of-excellence

We're working through a big volume ahead of the LFX Fall term and every ping pulls time away from the queue itself, so patience really does help us here.

Your PR is in the queue and we'll get to it. Thanks for your understanding.

[Prat260104]

@Prat260104 Thanks for the thoughtful reply and for sticking to one PR at a time. That's genuinely the right approach and it doesn't go unnoticed.

One thing to keep in mind: review order isn't FIFO. Things get picked up by area, urgency, and who has capacity, so a newer PR moving first doesn't mean yours was missed. Tagging maintainers to re-surface a PR is what the 30 July community guidelines on Discord and Respect Maintainer Time in the LF Standards of Excellence ask contributors to avoid: https://docs.linuxfoundation.org/lfx/mentorship/standards-of-excellence

We're working through a big volume ahead of the LFX Fall term and every ping pulls time away from the queue itself, so patience really does help us here.

Your PR is in the queue and we'll get to it. Thanks for your understanding.

Thank you for the clarification, @LexiNadolski.

That makes sense. I had assumed the review order was closer to FIFO, so I appreciate you explaining how reviews are actually prioritized.

I understand why re-surfacing PRs with mentions creates additional overhead, and I'll avoid doing that going forward. I'll patiently wait for the review.

I'm also looking forward to contributing for the upcoming LFX Fall term, so I wanted to make sure I was following the right process and expectations. Thanks again for taking the time to explain everything, and I appreciate all the work the maintainers are putting in during this busy period.

[Prat260104]

Hi @LexiNadolski ma’am, just wanted to check in and follow up on this PR. Whenever you get a chance, could you please take a look? Thanks!