rewriting them.

In PERF-341, we adjusted the static_replace middleware to try and
exclude static XBlock resource URLs from being interpreted as the marker
URLs used to signify course assets in course content.  Since they both
started with /static, this could, and did, cause issues where linking
directly to the assets of an XBlock within, say, one of its templates,
would lead to that link being rewritten and ultimately being incorrect.
The fix attempted to see if the link started with the prefix that all
static XBlock resource URLs start, and if so, it returned them
unmodified.

We incorrectly assumed that our testing captured all cases, and since
we're here, we know that this was wrong.  We weren't accounting for cases
when the URLs being generated had the STATIC_URL configuration value
prefixed -- https://example.com/static/xblock/.... -- and so our direct
check of seeing if such a URL started with "/static/xblock" would always
fail, leading to the erroneous rewriting and nonsensical output.

This fix checks if the link either starts with the prefix OR if it
starts with the STATIC_URL value and contains the prefix overall.  There
is a small overlap between the STATIC_URL and the prefix we check for,
so an inconsistency could arise down the line if we changed our
STATIC_URL to use a difference base directory, but our tests will at
least catch the issue now.