The component UIExtensionPoint was injecting IEnumerable<IUIExtension>
and then filtering on those.
As the number of IUIExtension grows, this operation grows at O(n).
Now we use UIExtensionsRegistry instead which use lookups. O(1)
Reported by @napoly.
## Actual behavior
Two tests were created. When we would run the tests through the runner,
ASP.NET wouldn't find the registered view of the plugin.
## Expected behavior
The second test should works find, ASP.NET should properly find the
views of the plugin when there are more than one test in the same test
run.
## Cause
If we detected that a plugin assemly was already in the AppDomain, then
we were not loading the ApplicationParts of such assembly.
This wasn't the case for the first test run, but would be after.
The reason for initially doing this was that long time ago, we would
test plugins by referencing them from BTCPaySevrer project. But since
this is not how we are doing things anymore, I think it is safe to
remove this "Feature".
This feature was broken anyway since we started loading plugins in their
own context, but this wouldn't happen with the old way of referencing
plugins from BTCPayServer. (#6851)
The richtext box had an annoying bug: If you switch to code view, modify
the code then save, the changes would be ignored.
One had to switch back to preview mode prior to save. (See
summernote/summernote#94 for more details)
We were previously saving the rates in the database in a JSONB blob
column. However, the volume of data ise consequential enough for
provoking timeouts during update.
Due to how postgres works, this also create bloat in the database that
isn't cleaned immediately.
This PR fixes this issue by saving the cache in files instead.
If a user go to store A, then lose access to store A, any attempt to
browse the home page will return a 403 error.
The user would then get stuck, unable to select a new store until he
clears the cache.
