Issue title: round_robin sporadic "Director xx returned no backend", when one backend is always offline
 Issue body: For a while I've been trying to figure out why we get sporadic 503 on client requests for a particular service.
When it happens, varnishlog reports `FetchError     Director pim_ cluster returned no backend`, but a running `varnishlog -g raw  -q '(Backend_health ~ "pim_a")` does NOT log anything but healthy probes during this time. 

The varnish part for this service is pretty basic: 
```
probe pim {
        .url = "/ping";
        .timeout = 1s;
        .interval = 5s;
        .window = 5;
        .threshold = 3;
}

backend pim_a {
    .host = "116.69.203.115";
    .port = "12500";
    .probe = pim;
}

backend pim_b {
    .host = "116.69.203.115";
    .port = "12500";
    .probe = pim;
}

sub vcl_init() {
...
    new pim_cluster = directors.round_robin();
    pim_cluster.add_backend(pim_a);
    pim_cluster.add_backend(pim_b);
..
}

sub vcl_recv {
    if(req.url ~ "^/pim") {
        set req.backend_hint = pim_cluster.backend();
    }
}
sub vcl_backend_response {
  if(bereq.url ~ "^/pim") {
    // No caching configured
    set beresp.ttl = 0s;
  }
}
```

The `pim_b` backend is a cold standby server, so it is not replying to probes and is thus always sick.

This have originally been observed on 6.3.1. Updated to 6.5.1 this week and problem persist. 
Grasping for straws, I edited the VCL and removed the `pim_b` cold standby server from the director. And since then I have not had a single 503, compared to several per day before.

So somehow suspecting that the cold standby server is somehow interfering with the director.. but cannot really understand why?
I've tried to write some VTC code to reproduce it but not successfully (but as it's my first attempt on VTC it's probably not perfect)

## Expected Behavior
`Director pim_ cluster returned no backend` should not occur when the probe have not failed, even with one backend always sick.

## Current Behavior
`Director pim_ cluster returned no backend` should seems to occur when one of the backends are always sick, even if the other servers probe have never failed.

Full varnishlog example (`varnishlog -q (BerespStatus == 503)`):
```
*   << BeReq    >> 541692578
-   Begin          bereq 541692577 fetch
-   VCL_use        reload_20201022_121905_2939
-   Timestamp      Start: 1605691593.972833 0.000000 0.000000
-   BereqMethod    GET
-   BereqURL       /pim/management/prometheus
-   BereqProtocol  HTTP/1.1
-   BereqHeader    User-Agent: Prometheus/2.7.1
-   BereqHeader    Accept: application/openmetrics-text; version=0.0.1,text/plain;version=0.0.4;q=0.5,*/*;q=0.1
-   BereqHeader    Accept-Encoding: gzip
-   BereqHeader    X-Prometheus-Scrape-Timeout-Seconds: 10.000000
-   BereqHeader    X-Forwarded-For: 116.69.203.115
-   BereqHeader    x-url: /pim/management/prometheus
-   BereqHeader    X-Forwarded-Host: 116.69.203.115:80
-   BereqHeader    X-ServiceName: pim
-   BereqHeader    host: 116.69.203.115:80
-   BereqHeader    X-Varnish: 541692578
-   VCL_call       BACKEND_FETCH
-   VCL_return     fetch
-   FetchError     Director pim_cluster returned no backend
-   FetchError     No backend
-   Timestamp      Beresp: 1605691593.972853 0.000020 0.000020
-   Timestamp      Error: 1605691593.972854 0.000021 0.000001
-   BerespProtocol HTTP/1.1
-   BerespStatus   503
-   BerespReason   Service Unavailable
-   BerespReason   Backend fetch failed
-   BerespHeader   Date: Wed, 18 Nov 2020 09:26:33 GMT
-   BerespHeader   Server: Varnish
-   VCL_call       BACKEND_ERROR
-   BerespHeader   Content-Type: text/html; charset=utf-8
-   BerespHeader   Retry-After: 5
-   VCL_return     deliver
-   Storage        malloc Transient
-   Length         286
-   BereqAcct      0 0 0 0 0 0
-   End
```

## Possible Solution

## Steps to Reproduce (for bugs)
Don't have one, but I see it daily, so any suggestions what I can test is appreciated.

## Context
Sporadic 503 to clients is unwanted.

## Your Environment
* Version used: varnish-6.5.1-0.0.el7.x86_64 rpm
* Operating System and version: RHEL 7.6, linux 3.10.0-957.5.1.el7.x86_64
* Source of binary packages used (if any) https://packagecloud.io/varnishcache/

 Comments: 
 Comment 0: could you please provide the output of
```
varnishstat -1f *pim_*
```
from shortly after you have seen a 503?
 Comment 1: Hm, they do happen a few times per day at most, so a bit tricky to catch that.

I could probably run that in a loop every few seconds and store to file, and then pick out the right file with the results after I see a 503?

 Comment 2: > I could probably run that in a loop every few seconds and store to file, and then pick out the right file with the results after I see a 503?

sounds reasonable
 Comment 3: Ok, here we go, got one:
```
*   << BeReq    >> 269300718
-   Begin          bereq 269300717 fetch
-   VCL_use        reload_20201203_082121_86458
-   Timestamp      Start: 1606996850.803563 0.000000 0.000000
-   BereqMethod    GET
-   BereqURL       /pim/xxxxx
-   BereqProtocol  HTTP/1.1
-   BereqHeader    User-Agent: python-requests/2.24.0
-   BereqHeader    Accept: */*
-   BereqHeader    X-Forwarded-For: xxxx
-   BereqHeader    X-Forwarded-Host: xxx
-   BereqHeader    host: xxxx
-   BereqHeader    Accept-Encoding: gzip
-   BereqHeader    X-Varnish: 269300718
-   VCL_call       BACKEND_FETCH
-   VCL_return     fetch
-   FetchError     Director pim_cluster returned no backend
-   Timestamp      Beresp: 1606996850.803588 0.000025 0.000025
-   Timestamp      Error: 1606996850.803590 0.000026 0.000001
-   BerespProtocol HTTP/1.1
-   BerespStatus   503
-   BerespReason   Backend fetch failed
-   BerespHeader   Date: Thu, 03 Dec 2020 12:00:50 GMT
-   BerespHeader   Server: Varnish
-   VCL_call       BACKEND_ERROR
-   BerespHeader   Content-Type: text/html; charset=utf-8
-   BerespHeader   Retry-After: 5
-   VCL_return     deliver
-   Storage        malloc Transient
-   Length         286
-   BereqAcct      0 0 0 0 0 0
-   End

```

This dump is from 12:00:53Z:
```
VBE.reload_20201203_082121_86458.pim_a.happy 18446744073709551615          .   Happy health probes
VBE.reload_20201203_082121_86458.pim_a.bereq_hdrbytes      1462655         5.45 Request header bytes
VBE.reload_20201203_082121_86458.pim_a.bereq_bodybytes            0         0.00 Request body bytes
VBE.reload_20201203_082121_86458.pim_a.beresp_hdrbytes       538806         2.01 Response header bytes
VBE.reload_20201203_082121_86458.pim_a.beresp_bodybytes   1794390368      6680.78 Response body bytes
VBE.reload_20201203_082121_86458.pim_a.pipe_hdrbytes               0         0.00 Pipe request header bytes
VBE.reload_20201203_082121_86458.pim_a.pipe_out                    0         0.00 Piped bytes to backend
VBE.reload_20201203_082121_86458.pim_a.pipe_in                     0         0.00 Piped bytes from backend
VBE.reload_20201203_082121_86458.pim_a.conn                       37          .   Concurrent connections used
VBE.reload_20201203_082121_86458.pim_a.req                      4229         0.02 Backend requests sent
VBE.reload_20201203_082121_86458.pim_a.unhealthy                   0         0.00 Fetches not attempted due to backend being unhealthy
VBE.reload_20201203_082121_86458.pim_a.busy                        0         0.00 Fetches not attempted due to backend being busy
VBE.reload_20201203_082121_86458.pim_a.fail                        0         0.00 Connections failed
VBE.reload_20201203_082121_86458.pim_a.fail_eacces                 0         0.00 Connections failed with EACCES or EPERM
VBE.reload_20201203_082121_86458.pim_a.fail_eaddrnotavail            0         0.00 Connections failed with EADDRNOTAVAIL
VBE.reload_20201203_082121_86458.pim_a.fail_econnrefused             0         0.00 Connections failed with ECONNREFUSED
VBE.reload_20201203_082121_86458.pim_a.fail_enetunreach              0         0.00 Connections failed with ENETUNREACH
VBE.reload_20201203_082121_86458.pim_a.fail_etimedout                3         0.00 Connections failed ETIMEDOUT
VBE.reload_20201203_082121_86458.pim_a.fail_other                    0         0.00 Connections failed for other reason
VBE.reload_20201203_082121_86458.pim_a.helddown                      0         0.00 Connection opens not attempted
VBE.reload_20201203_082121_86458.pim_b.happy                         0          .   Happy health probes
VBE.reload_20201203_082121_86458.pim_b.bereq_hdrbytes                0         0.00 Request header bytes
VBE.reload_20201203_082121_86458.pim_b.bereq_bodybytes               0         0.00 Request body bytes
VBE.reload_20201203_082121_86458.pim_b.beresp_hdrbytes               0         0.00 Response header bytes
VBE.reload_20201203_082121_86458.pim_b.beresp_bodybytes              0         0.00 Response body bytes
VBE.reload_20201203_082121_86458.pim_b.pipe_hdrbytes                 0         0.00 Pipe request header bytes
VBE.reload_20201203_082121_86458.pim_b.pipe_out                      0         0.00 Piped bytes to backend
VBE.reload_20201203_082121_86458.pim_b.pipe_in                       0         0.00 Piped bytes from backend
VBE.reload_20201203_082121_86458.pim_b.conn                          0          .   Concurrent connections used
VBE.reload_20201203_082121_86458.pim_b.req                           0         0.00 Backend requests sent
VBE.reload_20201203_082121_86458.pim_b.unhealthy                     0         0.00 Fetches not attempted due to backend being unhealthy
VBE.reload_20201203_082121_86458.pim_b.busy                          0         0.00 Fetches not attempted due to backend being busy
VBE.reload_20201203_082121_86458.pim_b.fail                          0         0.00 Connections failed
VBE.reload_20201203_082121_86458.pim_b.fail_eacces                   0         0.00 Connections failed with EACCES or EPERM
VBE.reload_20201203_082121_86458.pim_b.fail_eaddrnotavail            0         0.00 Connections failed with EADDRNOTAVAIL
VBE.reload_20201203_082121_86458.pim_b.fail_econnrefused          2630         0.01 Connections failed with ECONNREFUSED
VBE.reload_20201203_082121_86458.pim_b.fail_enetunreach              0         0.00 Connections failed with ENETUNREACH
VBE.reload_20201203_082121_86458.pim_b.fail_etimedout                2         0.00 Connections failed ETIMEDOUT
VBE.reload_20201203_082121_86458.pim_b.fail_other                    0         0.00 Connections failed for other reason
VBE.reload_20201203_082121_86458.pim_b.helddown                      0         0.00 Connection opens not attempted


Backend name                                   Admin              Probe   Health   Last change
reload_20201203_082121_86458.pim_a probe              5/5     healthy  Thu, 03 Dec 2020 08:21:22 GMT
 Current states  good:  5 threshold:  3 window:  5
  Average response time of good probes: 0.111181
  Oldest ================================================== Newest
  4444444444444444444444444444444444444444444444444444444444444444 Good IPv4
  XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX Good Xmit
  RRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR Good Recv
  HHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH Happy

reload_20201203_082121_86458.pim_b probe              0/5     sick     Thu, 03 Dec 2020 08:21:22 GMT
 Current states  good:  0 threshold:  3 window:  5
  Average response time of good probes: 0.000000
  Oldest ================================================== Newest
  ---------------------------------------------------------------- Happy

reload_20201203_082121_86458.pim_cluster       probe              1/2     healthy  Thu, 03 Dec 2020 08:21:22 GMT

                                               Backend            Weight  Health
                                               pim_a  -       healthy
                                               pim_b  -       sick


```

Not a single failed probe on pim_a from what I can see, and last change was several hours ago.
 Comment 4: thank you, we should be able to work with that. In my mind, this information does not leave any doubt.
 Comment 5: I think the issue is here that we made the deliberate decision to use a read-lock in [vmod_rr_resolve()](https://github.com/varnishcache/varnish-cache/blob/036f13d5b4b8d3fecced855c937d05f03db168e4/lib/libvmod_directors/round_robin.c#L72) despite updating `rr->nxt`. So when two resolve operations race, the same backend can be hit twice, in particular in the case at hand here where there are only two backends in the director and one is always sick.
IIRC, we made the decision to accept the round-robin director to not behave strictly round-robin with the benefit of better concurrency.
Some options I see:
* use a write lock. This would make the director work correctly, but serialize all resolve operations.
* use a local variable for each resolve call to iterate over backends and only update `rr->nxt` at the end. I think this would solve this issue while keeping the compromise
* reject this issue and recommend the [fallback director](https://varnish-cache.org/docs/trunk/reference/vmod_directors.html#directors-fallback)
 Comment 6: I think the fallback director is a nice workaround until a fix lands in a release.

Considering that this is already roundrobin-ish, the local variable option is probably fine and ultimately closer to correct.
 Comment 7: That was quick, great work!

Yes, the fallback director should cover our situation fine. Will switch to that and hopefully the situation should be gone. Will also go over our configs and see if we can clean out some old backends that we have lingering "just in case" but that will most likely never start up again..

Thanks for quick response!
{'source': 'GithubIssues', 'repo_name_with_owner': 'varnishcache/varnish-cache', 'issue_id': 755186978, 'repo_stars': 3195.0}