fix: Remove keyword only argument for RequestsMiddleware

[bradykieffer]

Remove keyword only arguments from request middleware. This causes
django to fail when attempting to load middleware. Django currently only
supports handlers being passed in as args.

Fixes #112 🦕

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[bradykieffer]

@googlebot I signed it!

[daniel-sanche]

Good catch, thanks! Do you think you could add a unit test to catch this going forward?

[bradykieffer]

Of course @daniel-sanche! I broke my rule about always pushing up a patch with a test, especially when there's a bug. I commented on #112:

A colleague of mine pointed out that this issue is related to the 2.0.0 update. Looking at Django's docs for 3.1 and 2.2 it doesn't seem like get_response is an optional, we could default it to non-null to fix this issue.

Do you know if code gen will cause this to fail going forward? If so, I think it's safe make get_response a required param

[daniel-sanche]

Of course @daniel-sanche! I broke my rule about always pushing up a patch with a test, especially when there's a bug. I commented on #112:

Perfect, thanks!

A colleague of mine pointed out that this issue is related to the 2.0.0 update. Looking at Django's docs for 3.1 and 2.2 it doesn't seem like get_response is an optional, we could default it to non-null to fix this issue.

Yeah, I just took a look at the django documentation and that seems to be the case, so that sounds like a good idea.

Do you know if code gen will cause this to fail going forward? If so, I think it's safe make get_response a required param

The code generator won't be an issue here, it should only impact /proto, /services, and /types. This file is pretty stand-alone

[bradykieffer]

Awesome, I added tests + made get_response a required param

[daniel-sanche]

Great, thanks for your contribution!