Python: Adgudime/python/serialization/settings

[AdityaGudimella]

Motivation and Context

This PR is the first of the PRs to use Pydantic in SemanticKernel. Any class that is a subclass
of pydantic.BaseModel is json serializable. This will be used to serialize the Kernel class.
Serialization of the Kernel is required for MLFlow integration.

Description

New dependencies:

• python-dotenv: Required for pydantic to support dotenv files.

Breaking Changes:

• .env file config keys have changed. See .env.example file for new keys
• Env Var OpenAI__ApiKey is no longer used in tests.
  It needs to be replaced in GitHub secrets with OPENAI_API_KEY
• Removed semantic_kernel.utils.settings::openai_settings_from_dot_env
• Removed get_oai_config fixture from tests/conftest.py

Other changes:

• (OpenAI) Settings can be loaded from
  • yaml files,
  • env vars, and,
  • .env files
    (in the same order of precedence)
• Added tests for
  -new functionality, and
  • to ensure (some of) the old functionality hasn't changed.

Next steps:
Repeat this PR for AzureOpenAISettings

Contribution Checklist

• The code builds clean without any errors or warnings
• The PR follows SK Contribution Guidelines (https://github.com/microsoft/semantic-kernel/blob/main/CONTRIBUTING.md)
• The code follows the .NET coding conventions (https://learn.microsoft.com/dotnet/csharp/fundamentals/coding-style/coding-conventions) verified with dotnet format
• All unit tests pass, and I have added new tests where possible
• I didn't break anyone 😄

[awharrison-28]

rationale for removing scope="session" ?

[AdityaGudimella]

Yet another thing I forgot to mention. Apologies. I wanted to ask you about this, and made this change so that I don't forget it.

Did you intend to use scope="session" in the fixture? The default scope is "function" which basically means that the fixture gets recreated for every test. Other fixture scopes, in my experience, cause issues down the line, once the number of tests increases. Since non-function scope fixtures are shared across multiple tests, if any one of those tests makes a change to the result returned by the fixture, downstream tests see the changed value. And since the order in which the tests are run is not fixed (especially across code changes), it sometimes leads to failures which are not easily reproducible either.

Fixtures with larger scopes are typically used when the object being constructed in the fixture is heavy and takes time to be created or if you need the shared property of the fixture. These fixtures don't seem to be satisfying either of these criteria, so I just wanted to check with you on them.

[awharrison-28]

Updated the target branch to feature-pydantic

[shawncal]

@awharrison-28 I see some failing UTs. Shall we help out @AdityaGudimella by merging to the feature-pydantic branch, and fixing the last few problems there?

[awharrison-28]

Moving this to draft

[shawncal]

@AdityaGudimella @awharrison-28 Closing as I understand this PR is superseded by the new ones. Please confirm or reopen if this PR is still applicable.