opts: ParseRestartPolicy: improve validation of max restart-counts

[thaJeztah]

• relates to api/types/container: add RestartPolicyMode type and enum moby/moby#44704
• depends on vendor: github.com/docker/docker 5b53ddfcdd1c (v25.0.0-dev) #4534

- Description for the changelog

- A picture of a cute animal (not mandatory but encouraged)

[codecov-commenter]

Codecov Report

Merging #4535 (8c8fdf2) into master (79f24c7) will decrease coverage by 59.41%.
The diff coverage is n/a.

❗ Current head 8c8fdf2 differs from pull request most recent head eced5eb. Consider uploading reports for the commit eced5eb to get more accurate results

Additional details and impacted files

@@            Coverage Diff             @@
##           master   #4535       +/-   ##
==========================================
- Coverage   59.40%       0   -59.41%     
==========================================
  Files         288       0      -288     
  Lines       24797       0    -24797     
==========================================
- Hits        14730       0    -14730     
+ Misses       9186       0     -9186     
+ Partials      881       0      -881     

[thaJeztah]

⚠️ For reviewers; I'm leaning two ways on this PR;

• 👍 validate early
• 👎 there IS a potential (although unlikely that these combinations could be supported by a future API version
• 👍 then again, the CLI does not support "future" versions of the API
• 👍 and .. there's already code invalidating "unknown" restart policies
• 🤷‍♂️ so I guess this doesn't make things worse

[thaJeztah]

Honestly, I'm still a bit on the fence on this one, and not sure how much validation we can do on the client side (as "what's supported" may change on the daemon side, and even between API versions).

To some extent considering if we should go the reverse; just parse the general format, and let the daemon return errors where things are invalid.

[vvoland]

I'm kinda neutral here - even if we'd change anything, that would still be gated by the API version which would require a newer CLI anyway.

But on the other hand... We will have the error message even without it, so there's no real gain for the UX.

[vvoland]

@thaJeztah are we still considering this?

[thaJeztah]

I need to look at this one again; it's probably not urgent, so might be fine for later