Fix incorrect reference to SimpleHttpOperator in 3.0.0 release notes

[dadonnelly316]

This PR removes an invalid reference to SimpleHttpOperator in the 3.0.0 release notes under the Provider Refactor & Standardization section. SimpleHttpOperator was not moved from airflow core to apache-airflow-providers-standard. It was under the http provider and removed in airflow 3.0.0 in place of the HttpOperator.

closes: #50712

---

^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code changes, an Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in a newsfragment file, named {pr_number}.significant.rst or {issue_number}.significant.rst, in airflow-core/newsfragments.

[boring-cyborg]

Congratulations on your first Pull Request and welcome to the Apache Airflow community! If you have any issues or are unsure about any anything please check our Contributors' Guide (https://github.com/apache/airflow/blob/main/contributing-docs/README.rst)
Here are some useful points:

• Pay attention to the quality of your code (ruff, mypy and type annotations). Our pre-commits will help you with that.
• In case of a new feature add useful documentation (in docstrings or in docs/ directory). Adding a new operator? Check this short guide Consider adding an example DAG that shows how users should use it.
• Consider using Breeze environment for testing locally, it's a heavy docker but it ships with a working Airflow and a lot of integrations.
• Be patient and persistent. It might take some time to get a review or get the final approval from Committers.
• Please follow ASF Code of Conduct for all communication including (but not limited to) comments on Pull Requests, Mailing list and Slack.
• Be sure to read the Airflow Coding style.
• Always keep your Pull Requests rebased, otherwise your build might fail due to changes not related to your commits.
  Apache Airflow is a community-driven project and together we are making it better 🚀.
  In case of doubts contact the developers at:
  Mailing List: dev@airflow.apache.org
  Slack: https://s.apache.org/airflow-slack

[dadonnelly316]

I just ran the pre-commits locally and generated a reproducible_build.yaml. I will commit it after I validate that the error I'm now getting on the "Check top-level breeze deps" check is due to a misconfiguration in my local environment

[pierrejeambrun]

Most likely you did a bad rebase, can you fix the branch so the PR only contains the relevant change.

Thanks

[dadonnelly316]

sounds good - I will fix the branch

[eladkal]

@dadonnelly316 can you fix the doc entry and resolve conflicts + rebase?

[dadonnelly316]

yes working on this now

[boring-cyborg]

Awesome work, congrats on your first merged pull request! You are invited to check our Issue Tracker for additional contributions.

[github-actions]

Backport failed to create: v3-0-test. View the failure log Run details

Status	Branch	Result
❌	v3-0-test

You can attempt to backport this manually by running:

cherry_picker 71f4224 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

[eladkal]

Raised #53661 for backport to v3-0-test
We can't autobackport becasue of the hash in reproducible_build.yaml

[dadonnelly316]

@eladkal - Why did the auto-backport fail? I'd like to be aware should I contribute again in the future

[potiuk]

@eladkal - Why did the auto-backport fail? I'd like to be aware should I contribute again in the future

Because ut generated conflicts - we have certain pre-commits that are run in certain situations. Or sometimes the branches diverged too much and same files changed in both branches differently - or there were some previous changes that also changed that file and they have not been backported. There are many reasons why "auto" backport can fail and if this happens - the bot will give exact instructions what you should do - including step "resolve all conflicts".

This is somewhat often when you cherry-pick stuf - that you should resolve conflicts manually - especially when the branches diverge by a few hundreds or few thousands commits (which is the case now).

[potiuk]

You can attempt to backport this manually by running:

cherry_picker 71f4224 v3-0-test

This should apply the commit to the v3-0-test branch and leave the commit in conflict state marking
the files that need manual conflict resolution.

After you have resolved the conflicts, you can continue the backport process by running:

cherry_picker --continue

Those instructions are pretty clear I think (as long as you read them of course).