usb_rndis: synchronize writes

The write function can be called concurrently by multiple threads. The
way it is implemented now means this desn't work, since there is no
guarantee the correct thread will be released from the semaphore by the
USB completion callback.

I tried to allow mutiple requests to run "in parallel" (really letting
the USB stack schedule them) by having he callback track which thread to
wake up (using send_message/receive_message as a synchronization tool)
but that still resulted in lockups.

The simplest solution is to ensure there is only a single thread doing a
write transaction at a time, which is achieved here with an extra mutex.

Fixes #18521.

Change-Id: I0b737acab6f5665cbe5b0e40a20ce99c16bdf21c
Reviewed-on: https://review.haiku-os.org/c/haiku/+/6707
Reviewed-by: Jérôme Duval <jerome.duval@gmail.com>

usb_rndis: accept incoming USB transfers up to 0x4000 size

As required by the spec. Then split them into multiple ethernet frames
as needed.

Fixes #17738.

Change-Id: I71ebff0fe1fc5c8a342d6d06b26eda8e87115e04
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5312
Reviewed-by: waddlesplash <waddlesplash@gmail.com>

usb_rndis: new driver for Android phones USB connection sharing

Based on usb_ecm and other native USB ethernet drivers which share a
similar structure.

References used to implement this:
- FreeBSD urndis driver
- [MS-RNDIS].pdf v20140501
- Microsoft list of RNDIS OIDs

TODO:
- Better handling of "request id" field to make sure the replies we get
match up with the requests we sent, and it could allow to have
multiple requests in flight. However, the FreeBSD driver doesn't
bother to implement this, if you only ever have one request in flight
and wait for a reply before sending another, this isn't really needed.
- Endian safety, this code will only work on little endian systems for
now. Several structures sent/received to/from the device must be little
endian, so on big endian platforms a lot of byteswapping will be needed,
or the code rewritten to use some smarter object and not a plain
struct for all of these.
- Investigate if it's possible to send/receive multiple ethernet frames
in a single USB transaction for better performance. Our driver
structure doesn't really allow for it unless the driver implements
some buffering on its own.

Change-Id: I2c6dacf0c1aeb6c7c1c112e9b16a63e586ea979a
Reviewed-on: https://review.haiku-os.org/c/haiku/+/5281
Reviewed-by: Adrien Destugues <pulkomandy@gmail.com>
Tested-by: Commit checker robot <no-reply+buildbot@haiku-os.org>