remove nonfunctional code from retirement

[deborahgu]

Summary

In edx_api.py, the CredentialsApi and EcommerceApi classes contain nonfunctional code.

• EcommerceApi.retire_learner
• EcommerceApi.get_tracking_key
• CredentialsApi.retire_learner

Additionally, ecommerce has, I believe, been deprecated in the open source organization, so theoretically that entire EcommerceApi class should be removed. However, I don't know if any instances are still using it anyway, so I'm uncomfortable saying the class is safe to go.

Acceptance Criteria

• Remove the methods from edx_api.py
  • EcommerceApi.retire_learner
  • EcommerceApi.get_tracking_key
  • CredentialsApi.retire_learner
• Remove any references to those methods.
  • There is definitely a reference in retire_one_user.py
  • I think that is probably except for the tests for those 2 Python files, but because of the way we get the name of the method from the configuration you aren't going to be able to do IDE/github autodetect, you're actually going to have to do searches for the code. But an initial search for that code doesn't find any other calls.
• Update the doc at driver_setup.rst

Background

Over on slack in #ecommerce, @MoisesGSalas wrote up a thread in 2024, referencing an earlier discussion on discourse about the retire_one_learner script:

There's an API call to the endpoint /api/v2/user/retire in ecommerce, but skimming through the code I never found it. Has this ever worked?

This references code that is now in edx-platform, but was previously in tubular.

At the time I answered, I think incorrectly, that no evidence that the endpoints in question (for both e-commerce and credentials) ever existed:

as far as I can tell the variants of this call were first added in May 2018 on these two lines, but as far as I can tell  no endpoint like that existed in edx-platform at that time either at user_ api/urls.py  or anywhere else.

I was confused at the time, because the history of this file, which has moved back and forth between tubular and edx-platform, makes it hard to track what worked at what times, and because the replace_usernames method from each class does exist on the two IDAs.

[m3hrab]

Hi @deborahgu , I’d like to take this issue and submit a PR. Please let me know if there’s anything specific I should be careful about.

[deborahgu]

I think the main thing to be careful about is that it is very difficult to track the history, and I am not positive that I verified that nothing that I flag there is used, so definitely triple check me. Note that, as per this link I put in the ticket body, automatic tools are not going to catch all of these references (because we get the method names out of configuration at runtime).

also thanks for picking it up! This code has been languishing for long enough that it's in a confusing state, so please feel free to ask questions if anything makes your head explode.