Improve error reporting in eds_ingest log

Soham (ExxonMobil contractor) was testing the basic flow. He had failure. But there is nothing in Xcom summary showing "gist" of the problem. The log file is very verbose and it is hard to extract the useful portion from lengthy messages. Run ID = 2fbae879-7ac5-4376-84c0-dc0be383a469 Environment is M23/Azure/Preship Soham's test case is to bring data from M23/AWS/Preship.

My feeling is that you can recreate the error by having stale token in the value of RefreshToken.

See this line.

[2024-06-05, 15:58:12 UTC] {oauth_refresh_token.py:53} INFO - Refresh Token in secret Vault is expired --- Generating new Refresh token

And later

2024-06-05, 15:58:13 UTC] {airflow_logger.py:158} ERROR -  Function Name : auto_generate_refresh_token 
 400 : Bad request  The server cannot process the request due to something to be a client error - Example malformed request syntax, invalid request message framing
 Details of the Exception : {"error":"unsupported_grant_type"}
NoneType: None

So, two suggestions -

1. Give outright failure if the token is stale. provide suitable error in Xcom summary. Then the user would know what to do as corrective action.

2. If the eds_ingest is capable of recreating refresh token since username, password is provided), then why did it fail here? Also provide guideline to the user for exact set of mandatory input fields when he/she is creating CSRE record.

cc @AshishSaxenaAccenture

EDS-Soham-Error-runID-2fbae879-7ac5-4376-84c0-dc0be383a469-old.txt

Acceptance Criteria:

• Code changes
• Code changes to be deployed on Dev. Environment
• Primary Testing in Dev. Environment[Primary Developer]
• Secondary Testing in Dev. Environment[Secondary Developer]
• Unit Test Cases
• MR Raised to master branch
• Internal Code Review
• Code approval
• MR approved[Merged to master]
• Integration Testing[Dev. Env]
• Pre-ship Testing[All CSP's]