[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging - gpr_log
In this CL we are migrating from gRPCs own gpr logging mechanism to absl logging mechanism. The intention is to deprecate gpr_log in the future.
We have the following mapping
1. gpr_log(GPR_INFO,...) -> LOG(INFO)
2. gpr_log(GPR_ERROR,...) -> LOG(ERROR)
3. gpr_log(GPR_DEBUG,...) -> VLOG(2)
Reviewers need to check :
1. If the above mapping is correct.
2. The content of the log is as before.
gpr_log format strings did not use string_view or std::string . absl LOG accepts these. So there will be some elimination of string_view and std::string related conversions. This is expected.
Closes#36595
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36595 from tanvi-jagtap:regex_test_core_iomgr_transport b0836fda1c
PiperOrigin-RevId: 633456839
[grpc][Gpr_To_Absl_Logging] Migrating from gpr to absl logging GPR_ASSERT
Replacing GPR_ASSERT with absl CHECK
These changes have been made using string replacement and regex.
Will not be replacing all instances of CHECK with CHECK_EQ , CHECK_NE etc because there are too many callsites. Only ones which are doable using very simple regex with least chance of failure will be replaced.
Given that we have 5000+ instances of GPR_ASSERT to edit, Doing it manually is too much work for both the author and reviewer.
<!--
If you know who should review your pull request, please assign it to that
person, otherwise the pull request would get assigned randomly.
If your pull request is for a specific language, please add the appropriate
lang label.
-->
Closes#36408
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36408 from tanvi-jagtap:tjagtap_core_security f9eaf45140
PiperOrigin-RevId: 627264425
As opposed to a flat directory, we now have the following structure:
- security
-context
- credentials
- composite
- fake
- google_default
- iam
- jwt
- oauth2
- plugin
- ssl
- transport
- util
We have not refactored the test code yet but this PR is already large
enough...
- Removing service_accounts credentials. These credentials just have
drawbacks compared to service_account_jwt_access credentials, notably
in terms for security.
- Renaming Google specific credentials with a Google prefix for C and
C++. This should be done as well for wrapped languages.
- This will take care of a potential issue with default credentials
where the slice pointer is casted as const char * for APIs that need a
null terminated string.