feat!: re-design No-op Provider

[sheepduke]

This PR

• Change the implementation of NoOpProvider.
  • Always return EvaluationError with ProviderNotReady code.
  • Remove the ability to change its behaviors via constructors, EvaluationContext etc.
• Add mockall dependency to mock FeatureProvider trait.
• Adjust usage of TypedBuilder.
  • Remove typed builder for EvaluationContext.
    => Since every field is optional so just use EvaluationContext::default().with_xx() to make it more unified.
  • Remove typed builder usage for some simple types. => Less code bloat.
• Adjust release-please pipeline.
  • Check format before building it. => Shorten pipeline build time when format is wrong.
  • Move "deny warnings" from lib.rs to build pipeline. => Better DX.

Related Issues

Notes

The main purpose of changing NoOpProvider is to make it more compliant with the spec. The spec mentioned that:

In the absence of a provider the evaluation API uses the "No-op provider", which simply returns the supplied default flag value.
The default NoOpProvider should return the supplied default flag value.

In Rust we leverage the type system to model this, instead of letting user provide a default value upon function invocation. When the flag evaluation fails due to any reason, an EvaluationError is returned, and the caller can do something like client.get_i32_value("flag_key", &context, None).unwrap_or(100) to provide a default value.

Now the NoOpProvider returns the default value of each data type if not configured. This is actually incorrect because the unwrap_or(..) part will never be executed (because it is always Ok) and the caller cannot chain a default value then.

Follow-up Tasks

How to test

[beeme1mr]

I am adding @gruebel because he expressed interest in getting involved with the Rust SDK.

[beeme1mr]

@sheepduke is the basic usage example on the readme still accurate? If I understand correctly, the fallback value is defined using .unwrap_or(false) instead of including it as an argument.

[gruebel]

nice work 🏅

[sheepduke]

@sheepduke is the basic usage example on the readme still accurate? If I understand correctly, the fallback value is defined using .unwrap_or(false) instead of including it as an argument.

Oh!!!! My apologies.

Added it. Really appreciate your reminder!