Use netavark create when creating networks

[ashley-cui]

Throwing containers/container-libs#610 at CI

Netavark now supports a new command, netavark create, which will take incomplete network configs, validate options, and return a completed config.
Vendor c/common/libnetwork, which uses the netavark create command, and adjust the tests accordingly.

Checklist

Ensure you have completed the following checklist for your pull request to be reviewed:

• Certify you wrote the patch or otherwise have the right to pass it on as an open-source patch by signing all
  commits. (git commit -s). (If needed, use git commit -s --amend). The author email must match
  the sign-off email address. See CONTRIBUTING.md
  for more information.
• Referenced issues using Fixes: #00000 in commit message (if applicable)
• Tests have been added/updated (or no tests are needed)
• Documentation has been updated (or no documentation changes are needed)
• All commits pass make validatepr (format/lint checks)
• Release note entered in the section below (or None if no user-facing changes)

Does this PR introduce a user-facing change?

Breaking change: The `no_default_route` driver option for the `podman network create` command now requires `true|false`. `0|1` are no longer supported. 

[packit-as-a-service]

tmt tests failed for commit bc7f1e5. @lsm5, @psss, @thrix please check.

[ashley-cui]

@Luap99 Would it be okay if we required no_default_route=true and discontinued support for no_default_route=1 due to rust serialization? Or would you prefer to continue supporting it? Would be a 6.0 breaking change

[packit-as-a-service]

tmt tests failed for commit 7d048a3. @lsm5, @psss, @thrix please check.

[packit-as-a-service]

tmt tests failed for commit 4559183. @lsm5, @psss, @thrix please check.

[packit-as-a-service]

tmt tests failed for commit f0d0fbc. @lsm5, @psss, @thrix please check.

[packit-as-a-service]

tmt tests failed for commit 86db852. @lsm5, @psss, @thrix please check.

[Luap99]

@Luap99 Would it be okay if we required no_default_route=true and discontinued support for no_default_route=1 due to rust serialization? Or would you prefer to continue supporting it? Would be a 6.0 breaking change

Generally speaking adding a custom parser on the rust side which can accepts 1 would not be to hard, but given the time I am fine to remove support for that. We can add it back if users complain

[Luap99]

LGTM

[Luap99]

for consistency it is best if we always vendor all modules to the same commit as they are all part of the same git repo, just in case you have to rebase/force push again. not blocking if tests go green

[Luap99]

you need to rebase on main to pick up #28597 for checkpoint failures

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[Luap99]

LGTM, @containers/podman-maintainers PTAL

[mheon]

Sure, LGTM