Config options should not affect the public API

[MabezDev]

Continuing the discussion from #2422 (comment)

We need to answer this question and then write the appropriate API-GUIDELINES to avoid violating this decision.

[bjoernQ]

My gut feeling is it shouldn't and only features should affect the public API - I don't have a great reasoning for that, but it doesn't feel right to change the API based on a configuration option

Technically the difference is "just" that other crates can activate a feature while only the binary-crate can set a config option

The linked comment however is a very interesting case:
Enabling CSI increases memory (and CPU?) usage but also we shouldn't allow users to call the related functionality if CSI is not enabled. If we cfg-away the API for that if it's not enabled, we are in fact changing the public API and make things fail at compile time - otherwise we would offer the API but return errors (preferred) or panic if CSI is not enabled

[MabezDev]

I agree, config options shouldn't affect the public API, I think we're better off adding those sorts of changes as features. We previously weren't keen on doing so because of the number of features we already had 😅, but we've reduced the number massively in recent months.

To action this change we need to:

• Remove the CSI config, and add it back as a feature
• Update the API-docs
• Look for any other configs that change the API (A quick skim and I think it's just CSI, but better to do a full check)

[bugadani]

Look for any other configs that change the API

Well I guess it's better if I respect this in the embassy-time PR 🥲

[Dominaezzz]

embassy-time is an interesting case since that's almost exclusively setup by the application rather than a library.

I say "almost" because frameworks are a thing, a library could be providing some kind of fn main() that sets up embassy time for ya.