### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### The Feature

Currently, for custom guardrail, if the guardrail fails (returns 500 or is down), it fails closed and all model requests will fail (here the guardrail is at localhost, but this is the same for a guardrail hosted remotely):

``` {"error":{"message":"Generic Guardrail API failed: Cannot connect to host localhost:56028 ssl:default [Multiple exceptions: [Errno 61] Connect call failed ('::1', 56028, 0, 0), [Errno 61] Connect call failed ('127.0.0.1', 56028)]","type":"None","param":"None","code":"500"}} ```

This is obviously a desirable goal for mature guardrails because otherwise security might be bypassed, but it makes evaluating guardrails harder since there is no guarantee they won't take your application down.

On the [Generic guardrail API](https://docs.litellm.ai/docs/adding_provider/generic_guardrail_api), we would want a flag such as:

```yaml fail_open_insecure: true ```

With the flag `false`, the current behavior would remain. With the flag `true`, 5xx responses would lead to the model request going forward as if the guardrail returned no a…