Adding ConfigClass for HTTPX

[mattjacksoncello]

This PR is to implement a config class to allow more control over httpx for things like certificate verification.

I have also merged in the changes from #92

Note: I have used Claude to help with the changes. I have reviewed everything but I am not the strongest coder so there may be mistakes that I have missed

[github-actions]

⚠️ This PR contains unsigned commits. To get your PR merged, please sign those commits (git rebase --exec 'git commit -S --amend --no-edit -n' @{upstream}) and force push them to this branch (git push --force-with-lease).

If you're new to commit signing, there are different ways to set it up:

Sign commits with gpg

Follow the steps below to set up commit signing with gpg:

1. Generate a GPG key
2. Add the GPG key to your GitHub account
3. Configure git to use your GPG key for commit signing

Sign commits with ssh-agent

Follow the steps below to set up commit signing with ssh-agent:

1. Generate an SSH key and add it to ssh-agent
2. Add the SSH key to your GitHub account
3. Configure git to use your SSH key for commit signing

Sign commits with 1Password

You can also sign commits using 1Password, which lets you sign commits with biometrics without the signing key leaving the local 1Password process.

Learn how to use 1Password to sign your commits.

[AndyTitu]

Won't deleting this block avoid these components from being properly exported from this package?

[AndyTitu]

@mattjacksoncello could you also add a section in the description about the use-case you are trying to unlock by passing certificate paths to the client and to httpx, and manual steps for testing this new feature you are attempting to add, as well as maybe add some unit tests that attempt to retrieve items while having this certificate setting turned on?

All these would help speed up the review.

[AndyTitu]

This change is not backwards compatible unfortunately, and other existing user scripts will break if we ever released this and those users updated to this new version. To support this new separation we'd have to release a new major version of the SDK, namely 2.0, and I'm not sure it's worth it only to separate the client initialisation function.

Don't get me wrong, I do agree that this would probably be a better pattern, it's just that I don't believe that this improvement alone is worth releasing a 2.0. Can we maybe revert this client separation and only keep the client config part of this PR?

[mattjacksoncello]

Thanks for the review Andy, will refactor the code

[mattjacksoncello]

@AndyTitu,

I've updated the PR to focus solely on the config class changes as requested. Here are the key updates:

1. Documentation:

   • Added a new section in USAGE.md documenting the primary use case for CA certificate verification with Connect server

2. Testing:

   • Created a new test file specifically for the config class implementation
   • Looking for feedback on test coverage and potential edge cases

3. Examples:

   • Added a new example demonstrating CA file usage in practice

Please review these changes and let me know if any adjustments are needed.