Removed old logging and implement Azure core logging coverage

[jay-most]

• Removed old logging
• Implement Azure core logging coverage for
  -ClientContext logging
  -ParallelQueryExecutionContextBase logging
  -RequestHandler logging

[kirankumarkolli]

@kushagraThapar , @moderakh , @simorenoh please take a look.

[moderakh]

is it possible to only log certain log messages conditionally for debug level? meaning if the log level is not debug then we don't log certain messages?

doesn't azure logger have something like logger.debug that we can use here?

[jay-most]

It's not there.

[jay-most]

let me check what others are doing.

[jay-most]

It's automatic...any logs that are written using a log level equal to or less than the one you choose will be emitted.

[moderakh]

ogs that are written using a log level equal to or less than the one you choose will be

most logging framework work that way. slf4j/log4j in java work same way.

@jay-most what are the supported log levels by the azure-logger?

logger.info is too noisy for this. Is there a lower log level (less noisy) which can be used here?

[jay-most]

... log level equal to or less than the one you choose will be emitted. sounds like it will be chatty at any level above debug.
error, warning, verbose, info

[moderakh]

thanks for explanation. In that case, if I understood correctly, it seems verbose is the closest to debug.

so as the old code was debug, isn't verbose more suitable here?

log.verbose("using prefetch");

I wonder if we can choose verbose here instead as it seems a more suitable replacement for debug?

[moderakh]

one minor comment regarding mapping of the old log levels to the new log levels. other than that LGTM. Thanks.

I think we should go with this:
debug -> verbose
info -> info
warn -> warning
error -> error

[simorenoh]

Mo made a good point and seems like it's been fixed, lgtm!