early-boot-config: Simplify conditional compilation and make local_file available to all platforms

[zmrow]

Issue number:
Fixes #1457

Description of changes:
This change simplifies the conditional compilation by re-exporting the appropriate PlatformDataProvider as the common name Platform. This allows us to remove all conditional bits from main by using Platform when retrieving user data.

It also makes local_file a common function that all platforms can use, rather than a "platform-like" module in itself. Currently, we only make use of it in the aws-dev variant.

Previously, `local_file` was an implementor of the
`PlatformDataProvider` trait.  This was a bit awkward, considering local
file is _not_ a platform.  It also meant it was a bit awkward to use
inside another provider.  This change makes `local_file` a function that
all platforms can use and makes use of it inside the `aws` module for
`aws-dev` variants.

This change uses `cfg` directives inside of `provider.rs` to compile the
appropriate `PlatformDataProvider` for the current variant.  It
re-exports the data provider as `Platform`, meaning that all conditional
compilation details are removed from `main.rs` and it can simply use
`Platform` instead of a specific platform trait implementor.

Testing done:

• Boot an aws-dev variant with and without a local file to ensure local file is read if it exists
• Boot an aws-k8s-1.19 variant to ensure user data is read properly (and local file isn't attempted).
• Boot a vmware-k8s-1.20 variant to ensure nothing broke there.

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[tjkirch]

I'm confused as to why local_file still has the cfg directive, since the PR says "It also makes local_file a common function that all platforms can use" - wouldn't we remove all conditionals on it, and let the data providers / platforms decide whether to call the function?

[zmrow]

We could for sure do that, but when compiling variants that don't use the code in the local_file module, we're going to get "unused" warnings like:

warning: constant is never used: `USER_DATA_FILE`
...
warning: function is never used: `local_file_user_data`

[zmrow]

I'm not really sure how we get around it other than hiding the whole module behind a cfg directive like I've done here... perhaps someone knows a trick I don't know?

[webern]

You could just silence the warning with #[allow(dead_code)] on the function that is sometimes unused. (need to look up the correct string there)

[zmrow]

Hm - I suppose we could do that but I like it a bit less. Are those really the only two options here? 🤔

[zmrow]

This (very good) article suggests the pattern I'm using: putting cfg directives on module imports to keep the actual code clean and not ignore any valid warnings.

IMHO let's keep the code as is unless we come up with something better.

[tjkirch]

I think not having a user data file is the normal case - is it worth a warning-level message?

[zmrow]

I think for variants that have the ability to use a local file it's worth having the message so users know that nothing was found there, similar to what we do for other sources.

[etungsten]

Can we have it as a info level message? I guess that would mean the message won't go to the console?

[zmrow]

I'll keep it as warn! for now to stay consistent with the rest of the program and ensure it outputs to the console as expected.

[zmrow]

^ Rebases on develop to fix the merge conflicts.

:( Sorry the rebase wasn't pushed separately.