Change logLevel as debug for XCOM returned value message

[KennethanCeyer]

related: #18264

---

The current Airflow version (2.x.x) supports Custom XCom Backends. and It means that the data from XCom could be larger than we think. (e.g. over 100GB)

However, PythonOperator and LevelDBOperator will try to show all of those data from XCom as a log message. This issue can cause web issues such as breaking the web page (due to browser memory issue or rendering speed issue). and It also will make it difficult to see the other log message from the task.

This PR suggests changing the logLevel info to debug, Because XCom returned value can be treated `debug purpose

^ Add meaningful description above

Read the Pull Request Guidelines for more information.
In case of fundamental code change, 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 UPDATING.md.

[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 Contribution Guide (https://github.com/apache/airflow/blob/main/CONTRIBUTING.rst)
Here are some useful points:

• Pay attention to the quality of your code (flake8, 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.
  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

[potiuk]

We need to be more careful with removing the log entry for Python operator which many people can rely on so conditional printing is much better, also unnecesary str() in level operator needs to be removed.

I suggest to split this change into two - one for Python operator (which is part of airlfow core package) and second for level one (which is in the google provider).

[KennethanCeyer]

@potiuk
Thanks for the quick comment.
The concern that this PR change will come as a side effect for many users seems valid.

I plan to do two things as follows.

1. Revert level one.
2. Rollback the logLevel debug to info of PythonOperator and Make a new optional parameter to control the display of the return_value log
   (default is True, It means display the return_value log)

[KennethanCeyer]

switch this PR to Draft due to the necessity to correct the related documents and write test specifications.

[potiuk]

Just one NIT: for the dosctring (thinking about future self wondering why this parameter is here).

[github-actions]

The PR most likely needs to run full matrix of tests because it modifies parts of the core of Airflow. However, committers might decide to merge it quickly and take the risk. If they don't merge it quickly - please rebase it to the latest main at your convenience, or amend the last commit of the PR, and push it with --force-with-lease.

[KennethanCeyer]

One quick question!
If the user uses DecoratedOperator as shown below through TaskFlow API,
there seems to be no way to block XCom return value logs.

@task
def my_task(): # Guess it is `_PythonDecoratedOperator`
    # ... process
    return large_data


with DAG(...) as dag:
    data = my_task() # It will make a huge log messages on Airflow UI
    my_second_task(data)

so, I think additional work will be required in a separate PR for TaskFlow API users.
What do you think?
Below are the locations that appear to require further work.

airflow/airflow/decorators/python.py

Lines 49 to 59 in a9772cf

	def __init__(
	self,
	**kwargs,
	) -> None:
	kwargs_to_upstream = {
	"python_callable": kwargs["python_callable"],
	"op_args": kwargs["op_args"],
	"op_kwargs": kwargs["op_kwargs"],
	}
	super().__init__(kwargs_to_upstream=kwargs_to_upstream, **kwargs)

[uranusjr]

Yes we should do something for this but separately. Maybe something like (just a random idea)

@task(..., log_return_value="DEBUG")
def my_task():
    ...
    return large_data

[KennethanCeyer]

@uranusjr
I see.
For that work, I will proceed by making another PR in the future.

[boring-cyborg]

Awesome work, congrats on your first merged pull request!

[uranusjr]

I split the task API change into another issue (referenced above)