bug: avoid using ok_or(anyhow!(...))

[hzxa21]

Describe the bug

@wenym1 found that anyhow!(...) can take several hundred ms to construct (#6131) and there are several places in our codebase using ok_or(anyhow!(...)), which eagerly constructs the anyhow error and can significantly increase call latency even if there is no error happening.

We should switch to ok_or_else, which perform lazy evaluation, and avoid this usage in the future.

Places to fix:
https://rust-lang.github.io/rust-clippy/master/#/or_fun_call
cargo clippy -- -W clippy::or_fun_call

• risingwave/src/rpc_client/src/lib.rs

  Line 246 in a1668f2

  .ok_or(RpcError::Internal(anyhow!(

• risingwave/src/rpc_client/src/lib.rs

  Line 264 in a1668f2

  .ok_or(RpcError::Internal(anyhow!("end of response stream")))??)

• risingwave/src/connector/src/parser/unified/avro.rs

  Line 130 in a1668f2

  let scale = match find_in_records("scale").ok_or(AccessError::Other(anyhow!(

• risingwave/src/connector/src/parser/unified/avro.rs

  Line 140 in a1668f2

  let value: BigInt = match find_in_records("value").ok_or(AccessError::Other(

• risingwave/src/connector/src/sink/coordinate.rs

  Line 64 in a1668f2

  let metadata = metadata.ok_or(SinkError::Coordinator(anyhow!(

• risingwave/src/stream/src/common/log_store/in_mem.rs

  Line 244 in a1668f2

  .ok_or(anyhow!("cannot get truncated epoch"))?;

• risingwave/src/connector/src/source/kafka/private_link.rs

  Line 150 in a1668f2

  .ok_or(anyhow!("Required property \"{property}\" is not provided"))

Error message/log

No response

To Reproduce

No response

Expected behavior

No response

How did you deploy RisingWave?

No response

The version of RisingWave

No response

Additional context

No response