fix: ensure rest unit tests have complete coverage

[kbandes]

This PR fixes gaps in the coverage of the generated unit tests, specifically when the rest transport is included.

This required refactoring the logic for required field handling into a separate static method corresponding to each API method with required fields in its request message. This allows that method to tested thoroughly without elaborate and repetitive mocking.

The intention for these changes is that the nox showcase_unit session should include both grpc and rest transports. However, there are several requirements before the noxfile should be changed:

1. The version of api_core with the rest operations client should be released (added in feat: add operations rest client to support long-running operations. python-api-core#311, not yet released).
2. The missing signature field fix in showcase should be released (fixed in fix!: add parent to method signature for Messaging.SearchBlurbs() gapic-showcase#930, not yet released).
3. The extended operations module should be moved to api_core and released (no PR yet that I know of).

Once these changes are release, the noxfile for the present repo should be updated to reference those releases. At that point, a full unit test of showcase with transport=grpc+rest should succeed and provide 100% coverage.

[vam-google]

LGTM, with one question.

Also, can you please provide the links to the corresponding PRs that are expected to be released to unblock 100% coverage (i.e. for the 3 items in the PR description)

[vam-google]

Why was this changed?

[kbandes]

This was at the request of software-dov. The change was made to api-core in a prior PR.

[kbandes]

Regarding related PRs: I'm not sure. I believe other people are making these changes and releasing them, I'm not sure of the timeline or PR numbers. The change to noxfile.py is small, but I won't know exactly how to do it until I know what the actual release numbers for showcase and api-core are.

[software-dov]

I would prefer it if we moved mutation to the caller, something like

__{{ method.name | snake_case }}_required_fields_default_values =  {
    {% for req_field in method.input.required_fields if req_field.is_primitive %}
        "{{ req_field.name | camel_case }}" : {% if req_field.field_pb.default_value is string %}"{{req_field.field_pb.default_value }}"{% else %}{{ req_field.field_pb.default_value }}{% endif %}{# default is str #}
    {% endfor %}
}


def _{{ method.name | snake_case }}_get_unset_required_fields(message_dict):
    return {k, v for k, v in __{{ method.name | snake_case }}_required_fields_default_values.items() if k not in message_dict}

    ....
    query_params.update(self._{{ method.name | snake_case }}_get_unset_required_fields(query_params)

[kbandes]

I can make this change.

[kbandes]

Done.

[software-dov]

It might be reasonable to have a test or two just for the hidden required fields update method.

[kbandes]

I'm not sure what you mean. Which method is hidden?

[kbandes]

Oh, I see, once we refactor as you describe above.
This is quite tricky to test, which is a lot of motivation for these changes. The problem is that typically, though not always, a required field is going to have an expected template in the http rule, so the default value will cause the transcoding to fail. This can be worked around by mocking the transcoding function, but it gets convoluted and ugly.

[kbandes]

I'm not sure what to do here. No code is un-covered. I would argue that testing this logic in the context of the api method itself doesn't necessarily add anything.

[kbandes]

Okay, I've added logic to test the actual api method with default-valued required fields.